Cache-Control有什么区别:max-age = 0和no-cache？

Question

标题Cache-Control: max-age=0意味着内容被认为是陈旧的(并且必须立即重新获取),这实际上与之相同Cache-Control: no-cache.

Answer 1

我有同样的问题,并在我的搜索中找到了一些信息(你的问题出现在其中一个结果).这就是我的决心......

Cache-Control标题有两面.一方是Web服务器(也就是"原始服务器")可以发送的地方.另一边是浏览器可以发送的地方(也就是"用户代理").

由源服务器发送时

我相信max-age=0简单地告诉缓存(和用户代理)响应是从一开始就过时的,因此他们应该If-Not-Modified在使用缓存副本之前重新验证响应(例如,使用标头),而no-cache告诉他们在使用缓存之前必须重新验证复制.从14.9.1什么是可缓存:

无缓存

...如果没有与原始服务器成功重新验证,缓存绝不能使用响应来满足后续请求.这允许源服务器甚至通过已配置为返回对客户端请求的陈旧响应的缓存来防止缓存.

换句话说,缓存有时可能会选择使用陈旧的响应(虽然我认为他们必须添加一个Warning标题),但no-cache他们说不管怎样都不允许他们使用过时的响应.在页面中生成棒球统计数据时,您可能希望获得SHOULD -revalidate行为,但是当您生成对电子商务购买的响应时,您需要MUST -revalidate行为.

虽然当你说不no-cache应该阻止存储时你的评论是正确的,但在使用时它可能实际上是另一个区别no-cache.我遇到了一个页面,Cache Control Directives Demystified,它说(我不能保证它的正确性):

在实践中,IE和Firefox已经开始处理no-cache指令,就像它指示浏览器甚至不缓存页面一样.我们大约一年前开始观察这种行为.我们怀疑这种变化是由于该指令广泛(和不正确)使用以防止缓存而引起的.

...

请注意,最近,"cache-control:no-cache"也开始表现得像"no-store"指令.

顺便说一句,在我看来,Cache-Control: max-age=0, must-revalidate基本上应该是同样的事情Cache-Control: no-cache.所以也许这是一种获得MUST -revalidate行为的方法no-cache,同时避免了no-cache做同样事情的明显迁移no-store(即没有任何缓存)？

由用户代理发送时

我相信shahkalpesh的答案适用于用户代理方.您还可以查看13.2.6消除多个响应的歧义.

如果用户代理发送具有Cache-Control: max-age=0(也称为"端到端重新确认")的请求,则沿途的每个高速缓存将重新验证其高速缓存条目(例如,具有If-Not-Modified报头)一直到源服务器.如果回复是304(未修改),则可以使用高速缓存的实体.

在另一方面,发送一个请求Cache-Control: no-cache(亦称"终端到终端重装")不重新确认和服务器必须不响应时使用的缓存副本.

Answer 2

最大年龄= 0

这相当于单击" 刷新",这意味着,除非我已经拥有最新的副本,否则请给我最新的副本.

无缓存

单击"刷新"时按住Shift键,这意味着,无论如何都只需重做所有内容.

Answer 3

现在这个老问题,但是如果有其他人像我一样通过搜索遇到这个问题,IE9会在使用后退和前进按钮时使用它来配置资源的行为.当使用max-age = 0时,浏览器将在后退/前进按下时查看资源时使用最后一个版本.如果使用no-cache,则将重新获取资源.

关于IE9缓存的更多细节可以在这个msdn缓存博客文章中看到.

Answer 4

在我最近使用IE8和Firefox 3.5进行的测试中,似乎两者都符合RFC.但是,它们与原始服务器的"友好性"不同.IE8 no-cache使用与语法相同的语义处理响应max-age=0,must-revalidate.但是,Firefox 3.5似乎被认为no-cache是等效的no-store,这会影响性能和带宽使用.

默认情况下,Squid Cache似乎永远不会存储任何带有no-cache标头的内容,就像Firefox一样.

我的建议是为public,max-age=0每个请求设置要检查新鲜度的非敏感资源,但仍然允许缓存的性能和带宽优势.对于具有相同考虑因素的每用户项目,请使用private,max-age=0.

我会no-cache完全避免使用它,因为它似乎被一些浏览器和流行的缓存混淆了功能相当于no-store.

此外,不要模仿Akamai和Limelight.虽然他们本质上运行大量缓存阵列作为他们的主要业务,并且应该是专家,但他们实际上有一种既得利益,可以从他们的网络下载更多的数据.谷歌也许不是一个很好的选择.他们似乎使用max-age=0或no-cache随机取决于资源.

Answer 5

max-age
    When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate 
its own cache entry, and the client has supplied its own validator in the request, the 
supplied validator might differ from the validator currently stored with the cache entry. 
In this case, the cache MAY use either validator in making its own request without 
affecting semantic transparency. 

    However, the choice of validator might affect performance. The best approach is for the 
intermediate cache to use its own validator when making its request. If the server replies 
with 304 (Not Modified), then the cache can return its now validated copy to the client 
with a 200 (OK) response. If the server replies with a new entity and cache validator, 
however, the intermediate cache can compare the returned validator with the one provided in 
the client's request, using the strong comparison function. If the client's validator is 
equal to the origin server's, then the intermediate cache simply returns 304 (Not 
Modified). Otherwise, it returns the new entity with a 200 (OK) response. 

    If a request includes the no-cache directive, it SHOULD NOT include min-fresh, 
max-stale, or max-age. 

礼貌:http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

不要接受这个作为答案 - 我将不得不阅读它以了解它的真实用法:)

Answer 6

我不是一个缓存专家,但Mark Nottingham是.这是他的缓存文档.他在参考文献部分也有很好的链接.

基于我对这些文档的阅读,看起来max-age=0可以允许缓存向"同一时间"进入的请求发送缓存响应,其中"同一时间"意味着足够接近它们同时看起来与缓存,但no-cache不会.

Answer 7

顺便说一下,值得注意的是,有些移动设备,特别是iPhone/iPad等Apple产品完全忽略了无缓存,无存储,Expires:0等标题,或者其他任何你可能试图强制它们不再重复使用的标题表单页面.

这让我们头疼不已,因为我们试图让用户的iPad问题说,在他们通过表单流程到达的页面上睡着了,比如说第2步,然后设备完全忽略了商店/缓存指令,据我所知,只是简单地从页面的最后状态获取页面的虚拟快照,即忽略明确告知的内容,而且不仅仅是,取一个不应存储的页面并且存储它而不再实际检查它,这导致各种奇怪的会话问题,以及其他.

我只是添加了这个,以防有人出现,无法弄清楚为什么他们会遇到会话错误特别是iphone和ipads,这似乎是这个领域最糟糕的罪犯.

我已经针对这个问题进行了相当广泛的调试器测试,这是我的结论,设备完全忽略了这些指令.

即使在常规使用中,我发现一些手机也完全无法检查新版本,例如,Expires:0然后检查最后修改日期以确定是否应该获得新版本.

它根本不会发生,所以我被迫做的是将查询字符串添加到我需要强制更新的css/js文件中,这会欺骗愚蠢的移动设备,使其认为它是一个它没有的文件,例如:my .css？v = 1,然后v = 2进行css/js更新.这很有用.

顺便说一句,用户浏览器,如果保留默认值,截至2016年,因为我不断发现(我们对我们的网站进行了大量更改和更新)也无法检查此类文件的最后修改日期,但查询字符串方法修复了这个问题.这是我注意到的客户和办公室人员,他们倾向于在浏览器上使用基本的普通用户默认设置,并且没有意识到css/js等缓存问题,几乎总是无法获得新的css/js,这意味着他们的浏览器的默认值(主要是MSIE/Firefox)没有做他们被告知要做的事情,他们忽略更改并忽略上次修改日期并且不验证,即使Expires:0明确设置.

这是一个很好的技术信息的好线程,但同样重要的是要注意这些东西在特别是移动设备中的支持有多糟糕.每隔几个月我就必须添加更多层保护,以防止他们无法遵循他们收到的标题命令,或者正确地插入这些命令.

Answer 8

关于缓存控制的 MDN 文档直接回答了这个问题：

\n

\n

大多数 HTTP/1.0 缓存不支持no-cache指令，因此历史上max-age=0曾被用作解决方法。但只有当缓存与源服务器断开连接时，才max-age=0可能导致过时的响应被重用。must-revalidate解决了这个问题。\n这就是为什么下面的示例相当于no-cache.

\n

Cache-Control: max-age=0, must-revalidate\n

\n

但现在，您可以简单地使用no-cache它。

\n

\n

还有关于缓存验证的 MDN 文档：

\n

\n

人们常说max-age=0and的组合与must-revalidate具有相同的含义no-cache。

\n

Cache-Control: max-age=0, must-revalidate \n

\n

max-age=0意味着\n响应立即过时，并且must-revalidate意味着一旦过时\xe2\x80\x94，就必须\n不经重新验证而重用它，因此在\n组合中，语义似乎与 相同no-cache。

\n

然而，这种用法max-age=0是以下事实的残余：HTTP/1.1 之前的许多\n实现无法处理\nno-cache指令\xe2\x80\x94，因此为了处理该限制，max-age=0被用作\n解决方法。

\n

但现在符合 HTTP/1.1 的服务器已得到广泛部署，因此没有理由使用该max-age=0-and-must-revalidate组合 \xe2\x80\x94\n您应该只使用no-cache.

\n

\n