标头Cache-Control: max-age=0
暗示内容立即被认为是陈旧的(并且必须重新获取),这实际上与Cache-Control: no-cache
.
8 回答
我有同样的问题,并在我的搜索中找到了一些信息(您的问题作为结果之一出现)。这是我确定的...
Cache-Control
标题有两个方面。一方面是网络服务器(又名“源服务器”)可以发送它的地方。另一边是浏览器可以发送的地方(又名“用户代理”)。
当由源服务器发送时
我相信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 Disambiguating Multiple Responses。
如果用户代理发送带有Cache-Control: max-age=0
(又名“端到端重新验证”)的请求,那么沿途的每个缓存都将重新验证其缓存条目(例如,使用If-Not-Modified
标头)一直到源服务器。如果回复为 304(未修改),则可以使用缓存的实体。
另一方面,发送带有Cache-Control: no-cache
(又名“端到端重新加载”)的请求不会重新验证,并且服务器在响应时不得使用缓存副本。
最大年龄=0
这相当于单击Refresh,这意味着,除非我已经有最新的副本,否则给我最新的副本。
无缓存
这是在单击刷新时按住Shift,这意味着无论如何都重做所有内容。
Old question now, but if anyone else comes across this through a search as I did, it appears that IE9 will be making use of this to configure the behaviour of resources when using the back and forward buttons. When max-age=0 is used, the browser will use the last version when viewing a resource on a back/forward press. If no-cache is used, the resource will be refetched.
Further details about IE9 caching can be seen on this msdn caching blog post.
在我最近对 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。虽然他们基本上将大规模缓存阵列作为他们的主要业务,并且应该是专家,但他们实际上对从他们的网络下载更多数据有既得利益。Google 也可能不是模拟的好选择。他们似乎根据资源使用max-age=0
或随机使用。no-cache
最大年龄 当通过 max-age=0 指令强制中间缓存重新验证时 它自己的缓存条目,并且客户端在请求中提供了自己的验证器, 提供的验证器可能与当前与缓存条目一起存储的验证器不同。 在这种情况下,缓存可以使用任一验证器发出自己的请求,而无需 影响语义透明度。 但是,验证器的选择可能会影响性能。最好的方法是 中间缓存在发出请求时使用自己的验证器。如果服务器回复 使用 304(未修改),则缓存可以将其现在经过验证的副本返回给客户端 200(OK)响应。如果服务器回复一个新的实体和缓存验证器, 但是,中间缓存可以将返回的验证器与提供的验证器进行比较 客户端的请求,使用强比较功能。如果客户端的验证器是 等于源服务器的,则中间缓存只返回 304(不是 修改的)。否则,它会返回带有 200(OK)响应的新实体。 如果请求包含 no-cache 指令,则不应包含 min-fresh, 最大陈旧或最大年龄。
礼貌:http ://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
不要接受这个作为答案 - 我将不得不阅读它以了解它的真正用法:)
我几乎不是缓存专家,但 Mark Nottingham 是。这是他的缓存文档。他在参考资料部分也有很好的链接。
根据我对这些文档的阅读,看起来max-age=0
可以允许缓存向“同时”进入的请求发送缓存响应,其中“同一时间”意味着它们看起来足够接近缓存,但no-cache
不会.
顺便说一句,值得注意的是,一些移动设备,尤其是 iPhone/iPad 等 Apple 产品完全忽略了诸如 no-cache、no-store、Expires: 0 之类的标头,或者您可能试图强制它们不重复使用过期的任何其他标头表单页面。
这让我们头疼不已,因为我们试图让用户的 iPad 说,在他们通过表单过程到达的页面上睡着了,比如步骤 2 of 3,然后设备完全忽略了商店/缓存指令,据我所知,它只是从页面的最后状态获取页面的虚拟快照,也就是说,忽略明确告知的内容,不仅如此,获取不应存储的页面, 并在没有实际检查的情况下存储它,这会导致各种奇怪的 Session 问题等等。
我只是添加这个以防有人出现并且无法弄清楚为什么他们会遇到特别是 iphone 和 ipad 的会话错误,这似乎是该领域迄今为止最严重的违规者。
我已经对这个问题进行了相当广泛的调试器测试,这是我的结论,设备完全忽略了这些指令。
即使在常规使用中,我发现某些手机也完全无法通过例如 Expires: 0 检查新版本,然后检查最后修改日期以确定是否应该获得新版本。
它根本不会发生,所以我被迫做的是向我需要强制更新的 css/js 文件添加查询字符串,这会欺骗愚蠢的移动设备认为它是一个它没有的文件,例如:我的.css?v=1,然后 v=2 用于 css/js 更新。这在很大程度上有效。
顺便说一句,用户浏览器如果保留其默认设置,截至 2016 年,正如我不断发现的那样(我们对我们的网站进行了大量更改和更新)也无法检查此类文件的最后修改日期,但查询string 方法解决了这个问题。这是我注意到的客户和办公室人员,他们倾向于在浏览器上使用基本的普通用户默认设置,并且不知道 css/js 等的缓存问题,几乎总是无法获得新的 css/js 更改,这意味着他们的浏览器的默认设置,主要是 MSIE / Firefox,没有按照他们被告知的去做,他们忽略更改并忽略最后修改日期并且不验证,即使明确设置了 Expires: 0。
这是一个很好的线程,有很多很好的技术信息,但同样重要的是要注意对这些东西的支持在特别是移动设备中有多糟糕。每隔几个月,我就必须添加更多的保护层,以防止他们无法遵循他们收到的标题命令,或者正确地解释这些命令。
(令人惊讶的是)没有提到的一件事是,请求可以使用max-stale
指令明确指示它将接受陈旧数据。在这种情况下,如果服务器以 响应max-age=0
,缓存将只考虑响应陈旧,并且可以自由地使用它来满足客户端的请求[它要求潜在的陈旧数据]。相比之下,如果服务器发送no-cache
的确实胜过客户端(带有max-stale
)对陈旧数据的任何请求,因为缓存必须重新验证。