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

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

我有同样的问题,并在我的search中find一些信息(你的问题是作为结果之一)。 这是我确定的

Cache-Control头有两个方面。 一方面是networking服务器(也就是“原始服务器”)可以发送的地方。 另一方面是浏览器(也就是“用户代理”)可以发送的地方。


当由原始服务器发送时

我相信max-age=0只是告诉caching(和用户代理),响应从一开始就是陈旧的,所以他们应该在使用caching副本之前重新validation响应(例如用If-Not-Modified头) , no-cache告诉他们在使用caching副本之前必须重新validation。 从14.9.1什么是可caching的 :

无caching

…caching绝不能使用响应来满足后续的请求,如果没有成功的对源服务器进行重新validation。 这允许源服务器甚至通过已configuration为对客户端请求返回陈旧响应的高速caching来防止高速caching。

换句话说,caching有时可能会select使用陈旧的响应(尽pipe我相信他们必须添加一个Warning头),但no-cache表示不pipe怎么说都不允许使用陈旧的响应。 也许你会希望在页面中生成棒球统计数据时应该使用SHOULD -revalidate行为,但是当你生成对电子商务购买的响应时,你会想要MUST -revalidate行为。

虽然你说你的评论是正确的,当你说no-cache不应该阻止存储,它可能实际上是使用no-cache另一个区别。 我遇到了一个页面, caching控制指令揭秘 ,说(我不能保证其正确性):

实际上,IE和Firefox已经开始将no-cache指令视为指示浏览器不要caching页面。 大约一年前我们开始观察这种行为。 我们怀疑这种改变是由于广泛使用这个指令来防止caching。

注意最近,“cache-control:no-cache”也开始performance得像“no-store”指令。

另外,在我看来, Cache-Control: max-age=0, must-revalidate应该基本上意味着与Cache-Control: no-cache一样的事情。 所以,也许这是获得no-cacheMUST -revalidate行为的一种方法,同时避免no-cache明显迁移到与no-store一样的事情(即不caching任何东西)?


当由用户代理发送时

我相信shahkalpesh的答案适用于用户端的一面。 你也可以看看13.2.6消除多重回应 。

如果一个用户代理发送一个带有Cache-Control: max-age=0 (又名“端到端重新validation”)的请求,那么沿途的每个caching都将重新validation其caching项(例如, If-Not-Modified标题)一直到原始服务器。 如果答复是304(未修改),则可以使用所caching的实体。

另一方面,使用Cache-Control: no-cache (又名“端到端重载”)发送请求不会重新生效,服务器在响应时不能使用caching副本。

老问题现在,但是如果有人像我一样通过search来解决这个问题,看起来IE9将使用这个来configuration使用后退和前进button时资源的行为。 当使用max-age = 0时 ,浏览器将在后退/前进按下查看资源时使用最后一个版本。 如果使用no-cache ,资源将被重新获取。

有关IE9caching的更多细节可以在这个msdncaching博客文章中看到。

最大年龄= 0

这相当于点击刷新 ,这意味着,给我最新的副本,除非我已经有最新的副本。

无caching

这是按住Shift的同时点击刷新,这意味着,无论如何,只需重做一切。

在我最近对IE8和Firefox 3.5的testing中,似乎都是RFC兼容的。 但是,它们与原始服务器的“友好”不同。 IE8使用与max-age=0,must-revalidate相同的语义处理no-cache响应max-age=0,must-revalidate 。 然而,Firefox 3.5似乎将no-cache视为等同于no-storeno-store ,这对于性能和带宽使用来说是非常吸引人的。

默认情况下,Squid Cache似乎永远不会像Firefox一样使用no-cache头来存储任何内容。

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

我会避免完全使用no-cache ,因为它似乎已经被一些浏览器和stream行的caching所混淆,成为no-store的function。

另外,不要模仿Akamai和Limelight。 虽然他们基本上将大量的cachingarrays作为他们的主要业务,并且应该是专家,但他们实际上有一个既定的兴趣,从networking上下载更多的数据。 Google也许不是一个很好的select。 他们似乎使用max-age=0no-cache随机取决于资源。

最大年龄
    当通过max-age = 0指令强制中间caching重新validation时 
它自己的caching条目,并且客户端在请求中提供了自己的validation器 
提供的validation器可能与当前存储在caching条目中的validation器不同。 
在这种情况下,caching可能会使用validation程序在不使用自己的请求 
影响语义透明度。 

    但是,validation器的select可能会影响性能。 最好的办法是为了 
中间caching在发出请求时使用自己的validation器。 如果服务器回复 
与304(未修改),则caching可以将其现在validation的副本返回给客户端 
与200(OK)的回应。 如果服务器回复一个新的实体和cachingvalidation器, 
但是,中间caching可以将返回的validation器与提供的validation器进行比较 
客户的要求,使用强大的比较function。 如果客户端的validation器是 
等于原始服务器,那么中间caching简单地返回304(不是 
改性)。 否则,它返回一个200(OK)响应的新实体。 

      如果请求包含no-cache指令,它不应该包含min-fresh,  
  最大陈旧,或最大年龄。

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

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

我不是一个caching专家,但马克诺丁汉是。 这是他的caching文档 。 他在“参考资料”部分也有很好的链接。

根据我对这些文档的阅读,看起来像max-age=0可以允许caching发送一个caching的响应到“同一时间”进来的请求,“同一时间”意味着足够接近他们看起来同时caching,但no-cache不会。

顺便说一下,值得注意的是,一些移动设备,特别是像iPhone / iPad这样的苹果产品,完全忽略了诸如无caching,无存储,Expires:0之类的标题,或者任何你可能试图迫使它们不再使用的过期表单页面。

这让我们头痛不已,因为我们试图解决用户的iPad问题,说他们在通过表单处理到达的页面上睡着了,比如说第3步中的第2步,然后设备完全忽略了商店/caching指令,并且据我所知,只需要从最后一个状态取得页面的虚拟快照,也就是忽略了明确告知的内容,不仅如此,取一个不应该存储的页面,并存储它没有再次实际检查,这导致各种奇怪的会话问题,等等。

我只是加了一些,以防万一有人出现,并且无法弄清楚为什么他们会发现会话错误,尤其是iphones和ipad,这似乎是这个地区最糟糕的罪犯。

我已经做了相当广泛的debugging器testing这个问题,这是我的结论,设备完全忽略这些指令。

即使在经常使用,我发现一些手机也完全无法检查新版本通过说,过期:0然后检查最后修改date,以确定是否应该得到一个新的。

它根本不会发生,所以我被迫做的是添加查询string到我需要强制更新的CSS / js文件,它欺骗愚蠢的移动设备认为它是一个它没有的文件,如:我的.css?v = 1,那么对于css / js更新,v = 2。 这大体上工作

顺便说一句,如果用户浏览器保持其默认状态,截至2016年,随着我不断发现(我们对网站进行了大量更改和更新),也无法检查这些文件的上次修改date,但查询string方法修复了这个问题。 这是我注意到与客户和办公室的人谁倾向于在他们的浏览器上使用基本的普通用户的默认值,并没有意识到与css / js等的caching问题,几乎总是无法获得新的CSS / JS的变化,这意味着他们的浏览器(主要是MSIE / Firefox)的默认设置并没有按照他们的要求去做,他们忽略了更改,忽略了最后的修改date,并且不会进行validation,即使Expires:0是明确设置的。

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

不同之处在于no-cache(Firefox上没有存储)可以防止任何forms的caching。 这可以有效地防止安全内容被写入磁盘的页面以及即使使用后退button重新访问也应始终更新的页面。

max-age = 0表示caching条目已过期,需要重新validation,但不防止caching。 通常,浏览器仅在每个浏览器会话中validation一次资源,因此,在新会话中访问该网站之前,内容可能不会更新。

通常情况下,浏览器不会删除过期的caching条目,除非在浏览器caching满时收回新内容的空间。 使用no-store,no-cache允许显式删除caching条目。