Chrome是否忽略缓存控制：最大年龄？
背景：
- IIS 7
- AspNet 3.5网络应用程序
Chrome开发工具列出了对web应用主页（aspx js css图像）的98个请求。在以下请求中，css/图像文件的状态代码为200。没有缓存信息，浏览器每次都会询问服务器是否需要更新文件。OK.
在IIS 7中，我为缓存控制设置HTTP头，为“ressources”文件夹设置为6小时。在Chrome中，使用dev工具，我可以看到标题在响应中设置得很好：
Cache-Control: max-age=21600
但我仍然收到98个请求。。。我认为浏览器不应该请求一个ressource，如果它的到期日期没有达到，我希望请求的数量下降。。。
共有3个答案
在使用Cache-Control： max-age=xxx进行了一些测试之后：
- 按下重新加载按钮：忽略标题
- 输入相同的url任何标签（当前或不）：荣幸
- 使用JS（
window.location.reload（））：忽略 - 使用开发工具（未选择禁用缓存）或隐姓埋名不会影响
因此，开发时最好的选择是将光标放在omnibox中，然后按回车键而不是刷新按钮。
注意：右键单击刷新图标将显示刷新选项（普通、硬、空缓存）。难以置信的是，没有人会影响这些标题。
如果您在同一选项卡中重新加载，Chrome似乎忽略了您的Cache-Control设置。如果将URL复制到新选项卡并加载到那里，Chrome将尊重缓存控制标记并重用缓存中的内容。
例如，我有一个Ruby Sinatra应用程序：
#!/usr/bin/env ruby
require 'sinatra'
before do
content_type :txt
end
get '/' do
headers "Cache-Control" => "public, must-revalidate, max-age=3600",
"Expires" => Time.at(Time.now.to_i + (60 * 60)).to_s
"This page rendered at #{Time.now}."
end
当我不断地在同一个Chrome选项卡中重新加载它时，它会显示新的时间。
This page rendered at 2014-10-08 13:36:46 -0400.
This page rendered at 2014-10-08 13:36:48 -0400.
标题看起来像这样：
< HTTP/1.1 200 OK
< Content-Type: text/plain;charset=utf-8
< Cache-Control: public, must-revalidate, max-age=3600
< Expires: 2014-10-08 13:36:46 -0400
< Content-Length: 48
< X-Content-Type-Options: nosniff
< Connection: keep-alive
* Server thin is not blacklisted
< Server: thin
但是访问相同的URL时，http://localhost:4567/从多个新选项卡将从缓存中回收以前的结果。
我拿到了。GoogleChrome忽略Cache-Control或Expires标头，如果您在同一选项卡中对同一URI的另一个请求之后立即发出请求（通过单击刷新按钮，按F5键或按命令R）。它可能有一个算法来猜测用户真正想做什么。
测试缓存控件头的一种方法是返回一个带有自身链接的HTML文档。单击链接时，Chrome从缓存中提供文档。例如，将以下文件命名为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并将其粘贴到同一选项卡或其他选项卡中。
更新：在2017年1月26日发布的一篇Chrome帖子中，描述了之前的行为以及它是如何改变的，只对主要资源进行了重新验证，而不对子资源进行了重新验证：
用户通常会因为页面损坏或内容过时而重新加载。现有的重新加载行为通常可以解决断页问题，但通过定期重新加载（尤其是在移动设备上）来解决陈旧内容的效率低下。这个特性最初是在断页非常普遍的时候设计的，所以同时处理这两个用例是合理的。然而，随着网页质量的提高，这种最初的担忧现在变得不那么重要了。为了改善陈旧内容的使用情况，Chrome现在有一个简化的重新加载行为，只验证主资源并继续常规页面加载。这种新的行为最大限度地重用了缓存资源，降低了延迟、功耗和数据使用率。
在2017年1月26日发布的一篇脸书帖子中，有人提到他们发现一段代码Chrome在发布请求后使所有缓存的资源无效：
我们发现Chrome会重新验证通过POST请求加载的页面上的所有资源。Chrome团队告诉我们这样做的理由是，POST请求往往是做出更改的页面——比如购买或发送电子邮件——并且用户希望拥有最新的页面。
看来不再是这样了。
最后，描述了Firefox正在引入Cache-Control： immutable来完全停止资源的重新验证：
Firefox实现了我们的一个工程师的提议，为一些资源添加一个新的缓存控制头，以告诉浏览器这个资源永远不应该被重新验证。这个标题背后的想法是，开发人员向浏览器做出了额外的promise，即该资源在其最大寿命期间永远不会改变。Firefox选择以缓存控制的形式实现这个指令：不可变的头。
我希望这有助于解开重载之谜。
-
我已将服务器响应配置为包含
-
我们已经配置nginx服务器添加缓存控制头到公共和到期时间到1个月。但是当我们从浏览器发出请求时，客户端正在添加缓存控制：无缓存头。正因为如此，它每次都是新鲜下载内容，而不是提供缓存版本。 我怎样才能缓存静态文件？ 如果我从终端触发请求，服务器添加的缓存控制标头在响应标头中可见。
-
属性不适用于
-
我无法为存储桶中的图像设置缓存控制最大年龄标头。这些图像实际上存储在firebase存储桶中，如果这有什么区别的话。 我可以成功上传一个图像，并在响应中接收文件对象。然后，我将文件的缓存控制最大年龄头设置为31536000，如下所示： 当我访问公共url上的图像时(https://storage.googleapis.com/my-bucket-name.appspot.com/storageBu
-
使用 rax-plugin-pwa 插件，可以方便快捷的使用 Service Worker 控制缓存，以获得更快的加载速度。 首先，安装 build-plugin-rax-pwa 插件依赖： $ npm install build-plugin-rax-pwa --save 在工程配置 build.json 中添加 pwa 插件并配置缓存目标： { "plugins": [ [
-
我创建了一个web应用程序，它使用了一个下拉标签框。这在除了Chrome浏览器（版本21.0.1180.89)之外的所有浏览器中都很好用。 尽管字段和字段都具有属性，但Chrome坚持要显示该字段以前条目的下拉历史记录，这将抹掉tagbox列表。