Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

请求头中的 Cache-Control

  Cache-Control 不是响应头的专利,即使是从浏览器发起的请求,其头部也可能带有 Cache-Control。请求头中的 Cache-Control 最大的意义是提供一套客户端主动控制代理服务器缓存策略的方案。但由于存在安全风险,实际上目前几乎没有代理服务器实现这个规范。
  就像 HTTP 的 PUT 方法上传文件一样,这是存在安全风险的,所以很多服务器并不愿意实现它。
  为什么说有安全风险呢?代理服务器上的缓存策略不仅是为了加快访问速度,更重要的一点是保护上游服务,甚至保护更底层的数据库。如果代理服务器的缓存策略暴露给不可信的客户端控制,那么攻击者则可以强行关闭代理服务器的缓存,直接把请求发送到业务服务器上。如果业务服务器到数据库没有缓存或缓存也由下游请求头控制,那么攻击者就可以击穿代理服务器和业务服务器,直接把数据库打爆。
  即使是内部服务调用,客户端是可信的。但由于下游服务的开发者并不知道上游服务的获取资源的代价,如果轻易把缓存关掉也会带来隐患。比如上游服务中的某个资源是基于一个慢查询得到的结果,如果下游服务关掉对方的缓存去频繁地刷新这个资源,数据库同样可能被打爆。
  所以在某种意义上,客户端请求头中的 Cache-Control 比开启 PUT 方法上传文件还要危险!
  但是规范总是太美,总是有人黑着眼眶去实现。比如 Chrome 在开发者工具中勾起 Disable cache 之后,请求头就会被加入一个 Cache-Control:no-cache。然并卵,因为并没有哪个服务器敢实现这个规范。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^