用 cURL 請求測試 ETag 瀏覽器緩存

時間 2019-12-20

原文原文鏈接

做者：Nic Raboy
翻譯：瘋狂的技術宅
原文： https://www.thepolyglotdevelo...
未經容許嚴禁轉載

最近，我一直在玩Netlify，結果我對內容交付網絡（CDN）常見的緩存策略愈來愈熟悉。有一種將 ETag標識符用於 Web 資源的策略。css

簡而言之，ETag 標識符是一個值，一般是一個散列，表明特定 Web 資源的版本。該資源與 ETag 值一塊兒緩存在瀏覽器中，而且服務器會在肯定特定的緩存資源是否已更改時使用該值。前端

咱們將探索怎樣經過簡單的 cURL 請求用 ETag 標識符模擬瀏覽器發出的請求，而是。程序員

首先，咱們將請求資源：面試

$ curl -I https://www.thepolyglotdeveloper.com/css/custom.min.css

HTTP/2 200 
accept-ranges: bytes
cache-control: public, max-age=0, must-revalidate
content-length: 7328
content-type: text/css; charset=UTF-8
date: Wed, 04 Sep 2019 00:41:04 GMT
strict-transport-security: max-age=31536000
etag: "018b8b0ecb632aab770af328f043b119-ssl"
age: 0
server: Netlify
x-nf-request-id: 65a8e1aa-03a0-4b6c-9f46-51aba795ad83-921013

在上述請求中，我僅從響應中請求了標頭信息。對於本文，響應體回覆的內容對咱們而言並不重要。segmentfault

注意 cache-control 和 etag 標頭以及響應代碼。瀏覽器

在 Netlify 下，cache-control 標頭告訴瀏覽器緩存資源，但也不信任緩存。這樣作是爲了使客戶端始終嘗試獲取最新資源。 etag 標頭表明資源的版本，並隨未來的請求一塊兒發送。若是服務器回覆說兩次請求之間的 etag 沒有改變，則響應將會帶有 304 代碼，從而將使用緩存的資源。緩存

所以，讓咱們用 cURL 檢查一下資源是否已進行了更改：bash

$ curl -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl"' https://www.thepolyglotdeveloper.com/css/custom.min.css

HTTP/2 304 
date: Wed, 04 Sep 2019 00:53:24 GMT
etag: "018b8b0ecb632aab770af328f043b119-ssl"
cache-control: public, max-age=0, must-revalidate
server: Netlify
x-nf-request-id: eca29310-c9bf-4742-87e1-3412e8852381-2165939

對相同資源的新請求，將包含 If-None-Match 標頭，其值爲前一個請求的 etag 哈希。服務器

注意，此次響應狀態代碼爲預期的 304。若是 etag 不一樣，則使用新的 etag 哈希產生 200 響應。微信

與壓縮的緩存資源進行交互

若是查看瀏覽器的網絡檢查器，您可能會注意到資源的 etag 哈希值附加了 -df 值。例如對於相同的資源，個人瀏覽器顯示如下內容：

018b8b0ecb632aab770af328f043b119-ssl-df

雖然類似，但與以前的 cURL 請求返回的 etag 哈希值並不徹底相同。嘗試使用上述 etag 值運行一個 cURL 請求：

$ curl -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl-df"' https://www.thepolyglotdeveloper.com/css/custom.min.css

HTTP/2 200 
accept-ranges: bytes
cache-control: public, max-age=0, must-revalidate
content-length: 7328
content-type: text/css; charset=UTF-8
date: Wed, 04 Sep 2019 01:03:13 GMT
strict-transport-security: max-age=31536000
etag: "018b8b0ecb632aab770af328f043b119-ssl"
age: 0
server: Netlify
x-nf-request-id: 2734ffab-c611-4fc9-841e-460f172aa3b4-1604468

響應不是 304 代碼，由於 -df 表示它是 URL 的壓縮版本。就目前而言，咱們的 cURL 請求針對的是 URL 的未壓縮版本。

Netlify 的支持工程師在這個論壇帖子中向我指出了這種差別。

在大多數狀況下，Web 瀏覽器將包含適當的標頭信息以使用壓縮資源，所以在 cURL中，咱們必須作一些不一樣的事。

爲了使 cURL 超越此限制，如下請求將起做用：

$ curl --compressed -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl-df"' https://www.thepolyglotdeveloper.com/css/custom.min.css

HTTP/2 304 
date: Wed, 04 Sep 2019 01:07:36 GMT
etag: "018b8b0ecb632aab770af328f043b119-ssl-df"
cache-control: public, max-age=0, must-revalidate
server: Netlify
vary: Accept-Encoding
x-nf-request-id: 65a8e1aa-03a0-4b6c-9f46-51aba795ad83-1301670

請注意，在上述請求中，咱們在 cURL 中用了 --compressed 標誌。結果收到了 304 響應，指示資源沒有更改，咱們應該使用本地緩存的副本。

或者，咱們能夠執行如下cURL請求：

$ curl -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl-df"' -H 'Accept-Encoding: gzip, deflate, br' https://www.thepolyglotdeveloper.com/css/custom.min.css

HTTP/2 304 
date: Wed, 04 Sep 2019 01:12:34 GMT
etag: "018b8b0ecb632aab770af328f043b119-ssl-df"
cache-control: public, max-age=0, must-revalidate
server: Netlify
vary: Accept-Encoding
x-nf-request-id: eca29310-c9bf-4742-87e1-3412e8852381-2432816

而不是用 --compressed 標誌，咱們包含了 accept-encoding 標頭。

一樣，Netlify 的 Luke Lawson 在這個論壇帖子中提供了有關壓縮版本的信息。

結論

您剛剛看到了如何用 cURL 模擬在 Web 瀏覽器中的相同緩存。因爲我是使用內容交付網絡（CDN）處理緩存的新手，所以對於測試緩存如何與任何給定資源的 etag 哈希一塊兒工做對我來講很是有用。 304 響應將始終比 200 響應更快地收到，而且有效負載更小，從而節省了帶寬和性能，同時又不犧牲內容的新鮮度。

從理論上講，CDN 會維護給定資源的版本信息，所以將可以驗證 etag 值的新鮮度。由瀏覽器決定 etag 是否陳舊。