nginx的ETag的失效

2016-11-21 181 views 0 likes

我缓存使用下面的代码的静态资源在我nginx.conf：nginx的ETag的失效

http { 
    ... 
    gzip on; 
    gzip_types *; 
    gzip_vary on; 
    ... 
    server { 
     ... 
     location /static { 
      alias /opt/static_root; 
      expires max; 
     } 
    } 
}

这足以设置以下HTTP头：

$ curl -I example.com/static/css/bootstrap.min.css 
Content-Length: 97874 
Last-Modified: Mon, 21 Nov 2016 18:30:33 GMT 
ETag: "58333d49-17e52" 
Expires: Thu, 31 Dec 2037 23:55:55 GMT 
Cache-Control: max-age=315360000

然而，即使Last-Modified日期比浏览器的缓存版本晚，我仍然看到该文件的旧版本（在Firefox 50.0和Chrome 54.0.2840.98上测试过）。

如何使ETag失效，以便每当我将差异部署到我的静态文件时，浏览器都能理解重新加载它们？我试过nginx -s reload，无济于事。

来源

2016-11-21 user14717

回答

当客户端发出条件请求来重新验证过期资源时，使用ETags。但在你的情况下，资源将不会到2037年过期！浏览器将继续从其缓存中提供资源，直至不需要与服务器进行检查。这就是你用Expires标题告诉它的内容。

通常情况下，如果您要做的远期过期，那么您必须通过更改名称来对资源进行版本控制。或者您可以将Expires更改为更短的内容，在这种情况下，当客户端尝试重新验证时将使用ETags。

来源

2016-11-21 22:11:08

好的，所以目前还没有机制可以（比如说）发送sha1哈希每个请求来决定是否重新下载一个资源，只有当哈希已经改变时才下载？ – user14717

@NickThompson：当然，你可以通过设置资源立即过期。在这种情况下，浏览器将为条件请求发送适当的头文件，服务器将使用ETag来确定资源是否已更改。（仅供参考，它[看起来像]（http://serverfault.com/a/690374）nginx不使用散列来确定ETags。） –

nginx的ETag的失效

回答

相关问题