Chrome会忽略ETag标头,只是使用内存caching/磁盘caching

如果我理解正确,那么使用ETags的stream程如下所述:

  • 浏览器将请求发送到服务器。 服务器用ETag发回图像
  • 浏览器随同ETag一起保存资源
  • 在下一个请求中,浏览器发送带有包含保存的ETag的头部If-None-Match的请求。

当返回响应时,chrome开发工具告诉我这些是我的头文件

 Cache-Control:max-age=7200 Connection:keep-alive Content-Type:image/png Date:Thu, 27 Apr 2017 13:42:57 GMT ETag:"b36f59c868d4678033d318a182658e18371df8f5" Expires:Thu, 27 Apr 2017 15:42:57 GMT Server:nginx Transfer-Encoding:chunked X-Debug-Token:873c8f X-Debug-Token-Link:http://localhost:8081/_profiler/873c8f 

现在,当我重新加载页面时,不会收集新的图像。 它通过Chrome的内存caching或磁盘caching保存,如您在这里看到的

Chrome开发标签

但为什么会这样呢? 我发送了一个ETag,为什么浏览器不向服务器发出另一个请求,而是使用它自己的caching?

我问的原因是,我们想要caching我们的图像,但只要他们改变,他们应该立即更新。 为什么Chrome会这样做?

更新
我只是注意到它在Firefox上的作用,所以这似乎是一个铬“function”,而不是一个configuration。

更新2
设置我的新标题像这样的图像

 Cache-Control:max-age=0, private Connection:keep-alive Content-Type:image/png Date:Thu, 27 Apr 2017 14:44:57 GMT ETag:"e5b18bdebe44ed4bba3acb6584d9e6a81692ee27" Expires:Fri, 27 Oct 2017 14:44:57 GMT Server:nginx Transfer-Encoding:chunked X-Debug-Token:3447a6 X-Debug-Token-Link:http://localhost:8081/_profiler/3447a6 

Chrome仍然使用磁盘caching来存放数据。 这是我现在的nginx

 location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ { access_log off; add_header Cache-Control "max-age: 0, must-revalidate"; } 

更新3
我只是做了一些进一步的研究。 只要设置了“过期”代码,Chrome就会使用内存或磁盘caching。 与max-age相同。 我不明白,即使设置了must-revalidate ,只要设置了Expiresmax-age=>0 ,Chrome就不会重新加载资源。

服务器正在告诉chrome这个资源在接下来的2个小时(7200秒)内是好的。 大概你的第二个要求比这个要早一些。

max-age: 0或者max-age: 0, must-revalidate可以更好的服务max-age: 0, must-revalidate 。 然后,虽然你永远不会得到一个完全缓存的操作(甚至不打扰服务器),你仍然可以让服务器发送304 Not Modified响应告诉浏览器它可以使用缓存的实体(并根据头文件(如果适用的话)),所以虽然只有约300字节的请求响应将被发送,而不是实体的千字节或更多。