相关疑难解决方法(0)

我们的调查向我们表明,并非所有浏览器都以统一的方式尊重http缓存指令.

出于安全原因,我们不希望在我们的应用程序某些网页缓存,有史以来,通过Web浏览器.这必须至少适用于以下浏览器:

• Internet Explorer 6+
• Firefox 1.5+
• Safari 3+
• Opera 9+
• 铬

我们的要求来自安全测试.从我们的网站注销后,您可以按后退按钮查看缓存页面.

来自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的答案了!

我的问题是:有时浏览器过度缓存了一些资源,即使我已经修改过它们.但是在F5之后,一切都很好.

我整个下午都研究过这个案子.现在我完全理解"Last-Modified"或"Cache-Control"的观点.我知道如何解决我的问题(只是.js？版本或显式max-age = xxxx).但问题仍然没有解决:浏览器如何在没有 "Cache-Control"的情况下处理响应头,如下所示:

Content-Length: 49675
Content-Type: text/html
Last-Modified: Thu, 27 Dec 2012 03:03:50 GMT
Accept-Ranges: bytes
Etag: "0af7fcbdee3cd1:972"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 24 Jan 2013 07:46:16 GMT 

当他们"进入酒吧"时,他们会清楚地缓存它们