拥有 HTTP 标头“Cache-Control：public”的风险是什么？答案

【问题标题】：What is the risk of having HTTP header "Cache-Control: public"?拥有 HTTP 标头“Cache-Control：public”的风险是什么？
【发布时间】：2010-07-27 00:06:55
【问题描述】：

Cache-Control HTTP/1.1 header 可以指定max-age以及缓存内容可以是public还是private，表示中间缓存是否可以缓存内容。

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

公开有什么风险？如果是公开的，哪些额外的地方可以缓存内容——例如是代理服务器吗？

如果网站像 Amazon.com，但用户是匿名的，那么可能没有太大的隐私问题？如果用户登录了，会不会有隐私问题，因为数据会通过地方并且数据是可见的。如果那个位置想要“坏”，它真的不需要关心Cache-Control: private。

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

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

【问题讨论】：

标签： http-headers cache-control

【解决方案1】：

Cache-Control: Public 的问题是响应可能被缓存并显示给不同的用户。如果您有一个显示私人数据的经过身份验证的应用程序，这将是一个问题。一般来说，您应该只将 public 用于静态页面，或者无论是什么用户发出请求都返回相同数据的页面。

【讨论】：

所以看起来即使是搜索结果...或者甚至是静态页面也可能不适合公开，因为共享同一台计算机的 2 个人可能希望相互了解缓存的网页。但我想无论Cache-Control 标头说什么，浏览器也应该有一个设置来将缓存设为私有。
谢谢。公共缓存是否有任何速度/性能优势？我不介意我的图像、字体或 css 等公开。

【解决方案2】：

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

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

公开

表示响应可能是被任何缓存缓存，即使它会通常是不可缓存或可缓存的仅在非共享缓存内。（看也授权，第 14.8 节，用于其他详细信息。）

私人

表示全部或部分响应消息旨在用于单个用户，不得被缓存共享缓存。这允许原点服务器声明指定的部分响应旨在用于只有一个用户并且不是有效的响应其他用户的请求。私有（非共享）缓存可以缓存响应。注意：这个用法 word private 仅控制响应可能被缓存，并且不能确保消息的私密性内容。

所以看起来更像是“共享缓存”而不是中间缓存。

【讨论】：