使用HTTP标头"Cache-Control:public"有什么风险？

Question

的Cache-ControlHTTP/1.1头部可以指定最大年龄以及所述高速缓存的内容是否可以是公共或私有的,指示中间高速缓存是否能够高速缓存的内容.

例如,Ruby on Rails expires_in()默认使用Cache-Control: private

将其公开的风险是什么？如果它是公共的,哪些额外的地方可以缓存内容 - 例如它是代理服务器吗？

如果网站像Amazon.com,但用户是匿名的,那么可能没有太多的隐私问题怎么办？如果用户登录,可能会出现隐私问题,因为数据通过位置并且数据可见.如果那个位置想要"坏",那么Cache-Control: private无论如何它真的不需要关心.

如果它是一个用户可以登录的网站,但网站只搜索鱼油和维生素等健康产品,等等.在这种情况下,涉及的隐私更少,因为它与Amazon.com不同,在那里有更多种类的产品,例如用户可以真正关心隐私问题的书籍.

话虽如此,有什么额外的优势Cache-Control: public？

Answer 1

问题Cache-Control: Public在于响应可以被缓存并显示给不同的用户.如果您具有显示私有数据的经过身份验证的应用程序,则会出现此问题.通常,您应该只对静态页面使用public,或者对于返回相同数据的页面,无论用户发出请求是什么.

Answer 2

我进一步发现了以下规范:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

上市

表示任何缓存都可以缓存响应,即使它通常只是非缓存或只能在非共享缓存中缓存.(有关其他详细信息,另请参阅授权,第14.8节.)

私人的

指示响应消息的全部或部分是针对单个用户的,并且不得由共享高速缓存进行高速缓存.这允许源服务器声明响应的指定部分仅针对一个用户,并且不是其他用户的请求的有效响应.私有(非共享)缓存可以缓存响应.注意:"private"一词的这种用法仅控制可以缓存响应的位置,并且无法确保邮件内容的隐私性.

所以它看起来更像是关于"共享缓存"而不是中间缓存.