Chrome 是否忽略了 Cache-Control: max-age? [英] Is Chrome ignoring Cache-Control: max-age?
问题描述
背景:
- IIS 7
- AspNet 3.5 网络应用
Chrome 开发工具列出了对 Web 应用程序主页的 98 个请求(aspx + js + css + 图像).在以下请求中，css/images 文件的状态代码为 200.没有缓存信息，浏览器每次都会询问服务器是否需要更新文件.好的.
Chrome dev tools lists 98 requests for the home page of the web app (aspx + js + css + images). In following requests, status code is 200 for css/images files. No cache info, browser asks server each time if file has to be updated. OK.
在 IIS 7 中，我为缓存控制设置了 HTTP 标头，ressources"文件夹设置为 6 小时.在 Chrome 中，使用开发工具，我可以看到响应头设置得很好:
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=21600
但我仍然收到了 98 个请求...我认为浏览器不应该请求一个资源，如果它的到期日期未到，我期望请求的数量会下降...
But 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...
推荐答案
我明白了.如果您在同一选项卡中对同一 URI 的另一个请求之后立即发出请求(通过单击刷新按钮，按F5 键或按 Command + R).它可能有一个算法来猜测用户真正想要做什么.
I got it. Google Chrome ignores the Cache-Control or Expires header 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.
测试 Cache-Control 标头的一种方法是返回一个带有指向自身的链接的 HTML 文档.单击链接时，Chrome 会从缓存中提供文档.例如，将以下文档命名为 self.html:
A way to test the Cache-Control header 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>
另一种选择是复制 URL 并将其粘贴到同一选项卡或其他选项卡中.
Another option is to copy the URL and paste it in the same tab or another tab.
更新:在 Chrome 发布于 2017 年 1 月 26 日，它描述了以前的行为以及它如何通过仅重新验证主要资源而不是子资源:
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:
用户通常会因为页面损坏或内容过时而重新加载.现有的重新加载行为通常可以解决损坏的页面，但定期重新加载无法有效解决陈旧的内容，尤其是在移动设备上.此功能最初是在断页很常见的时候设计的，因此同时解决这两个用例是合理的.然而，随着网页质量的提高，这个最初的担忧现在变得不那么重要了.为了改进陈旧内容用例，Chrome 现在具有简化的重新加载行为，以仅验证主要资源并继续常规页面加载.这种新行为最大限度地重用了缓存资源，从而降低了延迟、功耗和数据使用量.
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.
在 Facebook 帖子也在 2017 年 1 月 26 日发布，提到他们发现了一个一段代码 Chrome 在 POST 请求后使所有缓存的资源无效:
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:
我们发现 Chrome 会重新验证通过 POST 请求加载的页面上的所有资源.Chrome 团队告诉我们，这样做的理由是 POST 请求往往是进行更改的页面——比如购买或发送电子邮件——并且用户希望拥有最新的页面.
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.
现在好像不是这样了.
最后，描述Firefox正在引入Cache-Control: immutable以完全停止资源的重新验证:
Finally, it is described that Firefox is introducing Cache-Control: immutable to completely stop revalidation of resources:
Firefox 实施了我们一位工程师的提议，为某些资源添加新的缓存控制标头，以告诉浏览器永远不应重新验证该资源.此标头背后的想法是开发人员对浏览器的额外承诺，即该资源在其 max-age 生命周期内永远不会改变.Firefox 选择以 cache-control: immutable header 的形式实现这个指令.
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屋！
