发送“304 Not Modified”时设置“Cache-Control: public”是否合适针对存储在数据存储中的图片
在我问了一个关于如何为存储在Google App Engine数据存储中的图片发送“304 Not Modified”的问题后，我现在有一个关于Cache-Control的新问题。
我的应用现在会发送Last-Modified和Etag，但默认情况下，GAE还会发送Cache-Control: no-cache。根据这个页面：
根据RFC标准，“no-cache”指令告诉浏览器在从缓存中提供页面之前，必须先向服务器确认一下。[...] 实际上，IE和Firefox开始把no-cache指令当作是指示浏览器根本不缓存页面。
因为我确实希望浏览器能够缓存图片，所以我在我的代码中添加了以下一行：
self.response.headers['Cache-Control'] = "public"
根据之前提到的同一页面：
“cache-control: public”指令[...]告诉浏览器和代理服务器[...]这个页面可以被缓存。这对于不敏感的页面来说是好的，因为缓存可以提高性能。
我的问题是，这样做会对应用造成什么伤害吗？发送Cache-Control: must-revalidate是否更好，以“强制”浏览器重新验证（我想这就是最初发送Cache-Control: no-cache的原因）？
这个指令要求浏览器在从缓存中提供页面之前，必须先向服务器重新验证一下。注意，它隐含地允许浏览器缓存页面。
3 个回答
这对你的应用程序没有坏处。页面上提到的唯一风险是公共代理（比如互联网服务提供商使用的那些）可能会缓存你的图片。如果这张图片是保密的或者是特定用户的，你就不希望发生这种情况。在其他情况下，缓存其实正是你想要的效果。
可以查看这个链接：http://www.kyle-jensen.com/proxy-caching-on-google-appengine，里面对如何为谷歌应用引擎（GAE）设置缓存控制头部做了很好的解释。
如果你的内容没有受到HTTP认证或SSL保护，就不需要设置 Cache-Control: public。
可以试着设置 Cache-Control: max-age=nn（这里的nn是你希望缓存认为这个响应是新鲜的时间，单位是秒）。AppEngine 应该会去掉不缓存的设置。