来自RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
无缓存
如果no-cache指令没有指定字段名,那么缓存绝不能使用响应来满足后续请求,而不能成功地与源服务器重新验证.这允许源服务器甚至通过已配置为返回对客户端请求的陈旧响应的缓存来防止缓存.
因此它指示代理重新验证所有响应.
比较这个
必重新验证
当高速缓存接收到的响应中存在must-revalidate指令时,该高速缓存必须在该条目变为陈旧后才能响应后续请求而不首先使用源服务器重新验证它
因此,它指示代理重新验证陈旧的响应.
特别是关于no-cache,用户代理实际上是如何根据经验处理这个指令的？
什么是点no-cache,如果有must-revalidate和max-age？
看到这个评论:
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
无缓存
虽然这个指令听起来像是指示浏览器不缓存页面,但是有一个微妙的区别.根据RFC,"no-cache"指令告诉浏览器它应该在从缓存提供页面之前重新验证服务器.重新验证是一种简洁的技术,可以让应用程序保留带宽.如果浏览器缓存的页面没有更改,则服务器只向浏览器发出信号,并从缓存中显示该页面.因此,浏览器(理论上至少)将页面存储在其缓存中,但仅在与服务器重新验证后才显示该页面.在实践中,IE和Firefox已经开始处理no-cache指令,就像它指示浏览器甚至不缓存页面一样.我们大约一年前开始观察这种行为.我们怀疑这种变化是由于该指令广泛(和不正确)使用以防止缓存而引起的.
有没有人在这方面有更多的官方？
更新
当且仅当无法验证对表示的请求可能导致不正确的操作(例如无声的未执行的金融交易)时,服务器才应使用必须重新验证的指令.
这是我从未想到的事情.RFC表示不要轻易使用must-revalidate.问题是,对于Web服务,您必须采取负面视图并假设您的未知客户端应用程序最糟糕.任何陈旧的资源都有可能导致问题.
我刚才考虑的其他事情,没有Last-Modified或ETags,浏览器只能再次获取整个资源.但是对于ETags,我发现Chrome至少似乎在每次请求时重新验证.这使得这两个指令都没有实际意义或至少命名不佳,因为它们无法正确地重新验证,除非请求还包含其他标题,然后导致"始终重新验证".
我只是想让最后一点更清楚.通过设置must-revalidate但不包括ETag或Last-Modified,代理只能再次获取内容,因为它没有任何内容可以发送到服务器进行比较.
但是,我的经验测试表明,当ETag或修改后的头数据包含在响应中时,代理总是会重新验证,无论是否存在must-revalidate头.
所以点must-revalidate是强制"旁路缓存"时,它会过时,如果当您设置了一生/年龄这只能发生,从而must-revalidate设置上,没有年龄或其他头的响应,它实际上就变成等同于no-cache自响应将立即被视为陈旧.
- 所以我要终于标记Gili的答案了!
Gil*_*ili 177
我相信这must-revalidate意味着"一旦缓存过期,拒绝向用户返回陈旧的回复,即使他们说陈旧的回复是可以接受的".而no-cache暗示must-revalidate加上响应变得陈旧的事实.
如果响应是可缓存的10秒,然后must-revalidate踢在10秒后,而no-cache意味着must-revalidate0秒之后.
至少,这是我的解释.
小智 20
max-age=0, must-revalidate和no-cache不完全相同.使用must-revalidate,如果服务器没有响应重新验证请求,则浏览器/代理应该返回504错误.有了no-cache它,它只会显示缓存的内容,这可能是用户首选的内容(最好是让一些东西过时而不是任何东西).这就是为什么must-revalidate仅用于关键交易.
小智 14
根据Jeffrey Fox的解释no-cache,我在chrome 52.0.2743.116 m下进行了测试,结果表明它no-cache具有相同的行为must-revalidate,当服务器无法访问时,它们都不会使用本地缓存,而且,它们都将使用缓存,同时点击浏览器的返回/服务器无法访问时的前进按钮.如上所述,我认为至少在实施中max-age=0, must-revalidate是相同的no-cache.
| 归档时间： |
|
| 查看次数： |
119306 次 |
| 最近记录： |