no-cache和must-revalidate之间的差异

Question

来自RFC 2616

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

与之相比

必须-重新验证

当缓存接收到的响应中存在必须重新验证指令时，该缓存在条目过期后不得使用该条目来响应后续请求，而不首先使用原始服务器重新验证该条目

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

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

请参阅以下评论：

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

虽然这个指令听起来像是在指示浏览器不要缓存页面，但这有细微的区别。根据RFC，“no-cache”指令告诉浏览器，在从缓存中提供页面之前，它应该与服务器重新验证。重新验证是一种简单的技术，可以让应用程序节省带宽。如果浏览器缓存的页面没有更改，服务器只需向浏览器发出信号，页面就会从缓存中显示出来。因此，浏览器（至少在理论上）将页面存储在其缓存中，但仅在与服务器重新验证之后才显示它。实际上，IE和Firefox已经开始将no-cache指令视为指示浏览器甚至不要缓存页面。我们大约一年前开始观察这种行为。我们怀疑这一变化是由于广泛（且不正确）地使用该指令来阻止缓存而促使的。

有人有更官方的消息吗？

更新

直到现在我才把这件事放在心上。RFC说不要轻率地使用must-revalidate。问题是，对于web服务，您必须采取负面的观点，并对未知的客户端应用程序假设最坏的情况。任何陈旧的资源都有可能导致问题。

还有我刚才考虑过的其他问题，如果没有最后修改或ETAG，浏览器只能再次获取整个资源。然而，对于ETags，我观察到Chrome至少会对每一个请求进行重新验证。这使得这两个指令都没有意义，或者至少命名不好，因为它们不能正确地重新验证，除非请求还包括其他标头，这些标头会导致“始终重新验证”（always revalidate）。

我只想把最后一点说清楚。只需设置must-revalidate而不包括ETag或Last-Modified，代理就只能再次获取内容，因为它没有任何东西要发送到服务器进行比较。

然而，我的经验测试表明，当响应中包含ETag或修改的头数据时，代理总是重新验证，不管是否存在must-revalidate头。

因此，must-revalidate的作用是在过期时强制执行“绕过缓存”，这只有在您设置了生存期/时间后才会发生，因此，如果在没有时间或其他头的响应上设置了must-revalidate，它实际上就等同于no-cache，因为响应将立即被认为是过期的。

--所以我要最后标记Gili的答案！

Answer 1

我认为必须重新验证意味着：

一旦缓存过期，拒绝向用户返回过时的响应，即使他们说过时的响应是可以接受的。

而no-cache表示：

至少，这是我的解读。