nginx的ETag的失效

我緩存使用下面的代碼的靜態資源在我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的失效

回答

相關問題