HTTP 缓存：仅在缓存内容过期后*使用 ETag答案

【问题标题】：HTTP caching: is ETag only used *after* cached content has expiredHTTP 缓存：仅在缓存内容过期后*使用 ETag
【发布时间】：2015-07-04 17:51:01
【问题描述】：

因此，对于某些内容，服务器会发送一个 Cache-Control 标头，指示该内容最多可以缓存 120 秒，还发送一个带有某种内容哈希的 ETag 标头。

当浏览器下一次再次请求内容（相同的 URL）时，假设我们仍在 120 秒内，浏览器是否只是使用本地缓存的内容，而不管它之前是否收到过 ETag，也不管什么ETag 可能会说内容的新鲜度？

这似乎是 here 的建议（在“使用 ETag 验证缓存的响应”部分下）。

但是，我有一种情况，来自浏览器的内容请求似乎返回了标题，应该允许缓存下一个请求，但似乎从来没有。

这是来自 Chrome 的响应标头：

access-control-allow-origin:*
cache-control:private, max-age=300
date:Fri, 03 Jul 2015 21:22:33 GMT
etag:W/"208-nZVotiUd/tgf0oV0tBzi8w"

还有请求头：

Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
If-None-Match:W/"208-nZVotiUd/tgf0oV0tBzi8w"
User-Agent:Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36

在常规部分下：

Request Method:GET
Status Code:304 Not Modified

上面的状态码表明浏览器知道内容没有改变（通过304 response），这意味着确实将请求发送到服务器。尽管内容已经（应该）在本地缓存，并且仍在缓存期内。

那么为什么不只是从缓存中获取内容呢？

让我有点怀疑的是请求标头中的Cache-Control:max-age=0...大概是由 Chrome 放在那里的，但是...为什么？它有什么作用？我以为Cache-Control是服务器设置的，不是浏览器请求的？

编辑：我看到与加载在 html 中的远程 js 库类似的东西...响应标头建议应该使用缓存，但是每次都重新获取远程 js 并有时间延迟...尽管也得到了304 response。

【问题讨论】：

标签： html caching

【解决方案1】：

事实证明，您在浏览器中加载页面的方式会影响获取缓存资源的方式。见here。我每次都按 F5 重新加载页面，这似乎迫使浏览器检查是否需要再次获取资源，即使本地缓存的副本显然仍然有效。但是，如果您通过单击地址栏并按回车重新加载页面，它会遵循相关内容的缓存控制策略。反正这是我的理解。因此，以后当我查看我的页面内容如何被缓存时，我不会盲目地按 F5，我会通过在地址栏中按 Enter 来重新加载页面。

【讨论】：