从RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
无缓存
如果no-cache指令未指定字段名,则在未成功与源服务器重新验证的情况下,缓存不得使用响应来满足后续请求。这允许源服务器阻止缓存,即使是通过已配置为向客户端请求返回过时响应的缓存。
因此,它指示代理重新验证所有响应。
将其与
必须重新验证
如果高速缓存接收到的响应中存在MUST revalidate指令,则该高速缓存不得在条目过期后使用该条目来响应后续请求,除非首先向源服务器重新验证该条目
因此,它指示代理重新验证过时的响应。
特别是关于no-cache
,这是用户代理实际上从经验上对待这个指令的方式吗?
如果有must-revalidate
和max-age
,no-cache
还有什么意义
请参阅此评论:
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
无缓存
虽然这个指令听起来像是在指示浏览器不要缓存页面,但实际上有一个细微的区别。根据RFC的说法,“no- cache”指令告诉浏览器,在从缓存中提供页面之前,它应该与服务器重新验证。重新验证是一种巧妙的技术,可以让应用程序节省带宽。如果浏览器缓存的页面没有更改,服务器只会向浏览器发出信号,页面就会从缓存中显示出来。因此,浏览器(至少在理论上)将页面存储在其缓存中,但只有在与服务器重新验证后才显示它。在实践中,IE和Firefox已经开始处理no-cache指令,就好像它指示浏览器甚至不缓存页面一样。我们大约一年前就开始观察这种行为了。我们怀疑这一变化是由于广泛(且不正确)使用此指令来防止缓存造成的。
有人对此有更正式的说法吗?
更新
当且仅当验证表示上的请求失败可能导致不正确的操作时,服务器才应使用must revalidate指令,例如未执行的金融交易。
这是我直到现在才放在心上的东西。RFC说不要轻率地使用必须重新验证。问题是,对于web服务,您必须持负面看法,并为未知的客户端应用程序做最坏的打算。任何过时的资源都有可能导致问题。
还有一些我刚刚考虑过的问题,如果没有Last-Modified或ETags,浏览器只能再次获取整个资源。然而,在使用ETags时,我观察到Chrome似乎至少在每次请求时都会重新验证。这使得这两个指令都没有实际意义,或者至少命名不佳,因为它们不能正确地重新验证,除非请求还包括其他导致“总是重新验证”的头部。
我只想把最后一点说得更清楚。通过只设置must-revalidate
,但不包括ETag或Last-Modified,代理只能再次获取内容,因为它没有要发送到服务器进行比较的内容。
然而,我的经验测试表明,当响应中包含ETag或修改后的报头数据时,无论must-revalidate
报头是否存在,代理始终都会重新验证。
因此,must-revalidate
的要点是在它变得陈旧时强制“绕过缓存”,这只有在您设置了生命周期/年龄时才会发生,因此如果在没有年龄或其他标头的响应上设置了must-revalidate
,它实际上就等同于no-cache
,因为响应将被视为立即陈旧。
--所以我将最终标记Gili的答案!
https://stackoverflow.com/questions/18148884
复制相似问题