Chrome是否忽略Cache-Control：max-age？ [英] Is Chrome ignoring Cache-Control: max-age?
问题描述
- IIS 7
- AspNet 3.5网络应用程序
Chrome开发工具列出了98个网页应用主页的请求（aspx + js + css + images）。在以下请求中，css / images文件的状态码是 200 。没有缓存信息，每次浏览器都会询问服务器是否需要更新文件。 OK。
在IIS 7中，我为缓存控制设置了HTTP标头，对于ressources文件夹设置为6小时。在Chrome中，使用开发工具，我可以看到这个头文件很好地响应：
Cache-Control：max-age = 21600
但我仍然收到98个请求...我认为浏览器不应该请求一个资源到期日未达到，我期待的请求数量下降...
我明白了。如果您在请求同一个URI后立即发出请求，Chrome浏览器会忽略 Cache-Control 或 Expires （通过点击刷新按钮，按 F5 键或按 Command + R ）。它可能有一个算法来猜测用户真正想做什么。
一种测试 Cache-Control self.html ：
<！doctype html>
< html lang =en>
< head>
< meta charset =utf-8>
< title>测试页< /标题>
< / head>
< body>
< p>
< a href =self.html>链接到同一页面。< / a>
如果正确缓存，单击链接时不应使
发出请求。
< / p>
< / body>
< / html>
另一个选项是复制网址并将其粘贴到同一个标签或另一个标签中。
更新： Chrome发布于2017年1月26日 ，通过仅对主资源进行重新验证来描述以前的行为以及它如何改变，但不是子资源：
用户通常会重新加载，因为页面已损坏或内容看起来陈旧。现有的重新加载行为通常可以解决损坏的页面，但过时的内容无法有效地通过定期重新加载解决，特别是在移动设备上。此功能最初是在破损页面很常见的情况下设计的，因此一次解决两个用例是合理的。然而，随着网页质量的提高，这种原始关注现在变得不那么重要了。为了改善陈旧的内容使用案例，Chrome现在具有简化的重新加载行为，以仅验证主要资源并继续进行常规页面加载。这种新行为最大限度地提高了缓存资源的重用率，并降低了延迟，功耗和数据使用率。 Facebook的帖子还公布了2017年1月26日时，应提到的是，他们发现一个一段代码是Chrome在POST请求后使所有缓存资源无效：
我们发现Chrome会重新验证从发出POST请求加载的页面上的所有资源。 Chrome团队告诉我们这样做的理由是，POST请求往往是进行更改的页面 - 例如进行购买或发送电子邮件 - 并且用户希望拥有最新的页面。
看来情况已经不是这样了。
最后，被描述为Firefox正在引入
Cache-Control：immutable以完全停止对资源的重新验证：
Firefox实施了一项来自我们的工程师的建议，为一些资源添加一个新的缓存控制标题，以告诉浏览器该资源不应该被重新验证。这个标题背后的想法是，这是开发人员对浏览器的额外承诺，即该资源在其最大使用期限内永远不会更改。 Firefox选择以缓存控制：不可变头文件的形式实现这个指令。
我希望这有助于解决重载谜题。
Background:
- IIS 7
- AspNet 3.5 web app
Chrome dev tools lists 98 requests for the home page of the web app (aspx + js + css + images). In following requests, status code is
200for css/images files. No cache info, browser asks server each time if file has to be updated. OK.In IIS 7 I set HTTP header for cache control, set to 6 hours for the "ressources" folder. In Chrome, using dev tools, I can see that header is well set in response:
Cache-Control: max-age=21600But I still get 98 requests... I thought that browser should not request one ressource if its expiration date is not reached, and I was expecting the number of requests to drop...
解决方案I got it. Google Chrome ignores the
Cache-ControlorExpiresheader if you make a request immediately after another request to the same URI in the same tab (by clicking the refresh button, pressing the F5 key or pressing Command + R). It probably has an algorithm to guess what does the user really want to do.A way to test the
Cache-Controlheader is to return an HTML document with a link to itself. When clicking the link, Chrome serves the document from the cache. E.g., name the following document self.html:<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>Test Page</title> </head> <body> <p> <a href="self.html">Link to the same page.</a> If correctly cached, a request should not be made when clicking the link. </p> </body> </html>Another option is to copy the URL and paste it in the same tab or another tab.
UPDATE: On a Chrome post published on January 26, 2017, it is described what was the previous behavior and how it is changing by doing only revalidation of the main resource, but not of the sub-resources:
Users typically reload either because a page is broken or the content seems stale. The existing reload behavior usually solves broken pages, but stale content is inefficiently addressed by a regular reload, especially on mobile. This feature was originally designed in times when broken pages were quite common, so it was reasonable to address both use cases at once. However, this original concern has now become far less relevant as the quality of web pages has increased. To improve the stale content use case, Chrome now has a simplified reload behavior to only validate the main resource and continue with a regular page load. This new behavior maximizes the reuse of cached resources and results in lower latency, power consumption, and data usage.
In a Facebook post also published on January 26, 2017, it is mentioned that they found a piece of code were Chrome invalidates all cached resources after a POST request:
we found that Chrome would revalidate all resources on pages that were loaded from making a POST request. The Chrome team told us the rationale for this was that POST requests tend to be pages that make a change — like making a purchase or sending an email — and that the user would want to have the most up-to-date page.
It seems this is not the case anymore.
Finally, it is described that Firefox is introducing
Cache-Control: immutableto completely stop revalidation of resources:Firefox implemented a proposal from one of our engineers to add a new cache-control header for some resources in order to tell the browser that this resource should never be revalidated. The idea behind this header is that it's an extra promise from the developer to the browser that this resource will never change during its max-age lifetime. Firefox chose to implement this directive in the form of a cache-control: immutable header.
I hope this helps to untangle the reload mysteries.
这篇关于Chrome是否忽略Cache-Control：max-age？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
