caching - Cache-Control 的无缓存和必须重新验证之间的区别？

Question

来自 RFC 2616

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

no-cache

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.

因此它指示代理重新验证所有响应。

与此相比

must-revalidate

When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server

因此它指示代理重新验证陈旧响应。

特别是关于 no-cache，用户代理实际上是这样根据经验处理这个指令的吗？

如果有 must-revalidate 和 max-age，no-cache 有什么意义？

看到这条评论:

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

no-cache

Though this directive sounds like it is instructing the browser not to cache the page, there’s a subtle difference. The “no-cache” directive, according to the RFC, tells the browser that it should revalidate with the server before serving the page from the cache. Revalidation is a neat technique that lets the application conserve band-width. If the page the browser has cached has not changed, the server just signals that to the browser and the page is displayed from the cache. Hence, the browser (in theory, at least), stores the page in its cache, but displays it only after revalidating with the server. In practice, IE and Firefox have started treating the no-cache directive as if it instructs the browser not to even cache the page. We started observing this behavior about a year ago. We suspect that this change was prompted by the widespread (and incorrect) use of this directive to prevent caching.

有没有人对此有更官方的消息？

更新

The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could result in incorrect operation, such as a silently unexecuted financial transaction.

这是我直到现在都没有放在心上的事情。 RFC 说不要轻易使用 must-revalidate。问题是，对于 Web 服务，您必须持消极态度，并为您未知的客户端应用程序做最坏的打算。任何过时的资源都有可能导致问题。

还有一些我刚刚考虑过的事情，如果没有 Last-Modified 或 ETag，浏览器只能再次获取整个资源。然而，对于 ETag，我观察到 Chrome 至少似乎在每次请求时都会重新验证。这使得这两个指令都没有实际意义，或者至少命名不当，因为它们无法正确重新验证，除非请求还包含其他 header ，这些 header 无论如何都会导致“始终重新验证”。

我只想更清楚地说明最后一点。通过仅设置 must-revalidate 但不包括 ETag 或 Last-Modified，代理只能再次获取内容，因为它没有任何内容可发送到服务器进行比较。

但是，我的经验测试表明，当响应中包含 ETag 或修改后的 header 数据时，无论是否存在 must-revalidate header ，代理总是会重新验证。

所以 must-revalidate 的要点是在它变得陈旧时强制“绕过缓存”，这只有在您设置了生命周期/年龄时才会发生，因此如果 must- revalidate 设置在没有年龄或其他 header 的响应上，它实际上等效于 no-cache 因为响应将立即被视为陈旧。

-- 所以我要最终标记 Gili 的答案了!

Answer 1

我相信 must-revalidate 意味着:

Once the cache expires, refuse to return stale responses to the user even if they say that stale responses are acceptable.

鉴于 no-cache 意味着:

must-revalidate plus the fact the response becomes stale right away.

如果响应可缓存 10 秒，则 must-revalidate 会在 10 秒后启动，而 no-cache 意味着 must-revalidate 0 秒后。

至少，这是我的解释。