HTTP與快取相關的欄位
1. 通用欄位
欄位名稱 | 釋義 |
---|---|
Cache-Control | 控制快取具體的行為 |
Pragma | HTTP1.0時的遺留欄位,當值為"no-cache"時強制驗證快取 |
Date | 建立報文的日期時間(啟發式快取階段所用) |
2. response欄位
欄位名稱 | 釋義 |
---|---|
ETag | 伺服器生成資源的唯一標識 |
Vary | 代理伺服器快取的管理資訊 |
Age | 資源在快取代理中存貯的時長(取決於max-age和s-maxage的大小) |
3. request欄位
欄位名稱 | 釋義 |
---|---|
If-Match | 條件請求,攜帶上一次請求中資源的ETag,伺服器根據這個欄位判斷檔案是否有新的修改 |
If-None-Match | 和If-Match作用相反,伺服器根據這個欄位判斷檔案是否有新的修改 |
If-Modified-Since | 比較資源前後兩次訪問最後的修改時間是否一致 |
If-Unmodified-Since | 比較資源前後兩次訪問最後的修改時間是否一致 |
4. 實體欄位
欄位名稱 | 釋義 |
---|---|
Expires | 告知客戶端資源快取失效的絕對時間 |
Last-Modified | 資源最後一次修改的時間 |
協商快取(304)
If-modified-Since/Last-Modified
- 瀏覽器在傳送請求的時候伺服器會檢查請求頭
request header
裡面的If-modified-Since
,如果最後修改時間相同則返回304,否則給返回頭(response header
)新增last-Modified
並且返回資料(response body
)。
if-modified-since:Wed, 31 May 2017 03:21:09 GMT
if-none-match:"42DD5684635105372FE7720E3B39B96A"
複製程式碼
If-None-Match/Etag
- 瀏覽器在傳送請求的時候伺服器會檢查請求頭(
request header
)裡面的if-none-match
的值與當前檔案的內容通過hash演算法(例如 nodejs: cryto.createHash('sha1')
)生成的內容摘要字元對比,相同則直接返回304
,否則給返回頭(response header
)新增etag
屬性為當前的內容摘要字元,並且返回內容。
etag:"42DD5684635105372FE7720E3B39B96A"
last-modified:Wed, 31 May 2017 03:21:09 GMT
複製程式碼
請求頭last-modified的日期與響應頭的last-modified一致
請求頭if-none-match的hash與響應頭的etag一致
所用會返回Status Code: 304
強快取(200 from cache)
-
如果設定了
Expires
(XX時間過期)或者Cache-Control(http1.0不支援)
(經歷XX時間後過期)且沒有過期,命中cache
的情況下,from cache
不去發出請求。如果強刷(如ctrl+r)會發起請求,但是如果沒有修改會返回304
內容未修改,如果已經改變則返回新內容。max-age > Expires
。 -
expires/cache-control
雖然是強快取,但使用者主動觸發的重新整理行為,還是會採用快取協商的策略,主動觸發的重新整理行為包括點選重新整理按鈕、右鍵重新整理、f5重新整理、ctrl+f5重新整理等。 -
當然如果在控制檯裡面選中了
disable cahce
則無論如何都會請求最新內容(304協商快取、強快取都無效),因為1.不會檢查本地是否有快取。2.請求頭資訊(request header)既沒有If-Modified-Since也沒有If-None-Match來讓服務端判斷。位址列輸入的地址按下Enter鍵,該地址頁面請求(僅僅是該url)的request header
都會帶上cache-contro:max-age=0
,所以不會命中強快取,但是通過連結點選的地址會命中快取 -
chrome下檢視所有的from cache檔案:chrome://view-http-cache/
區別
- 觸發 200 from cache:
- 直接點選連結訪問
- 輸入網址按回車訪問
- 二維碼掃描
- 觸發 304:
- 重新整理頁面時觸發
- 設定了長快取、但Entity Tags沒有移除時觸發
流程圖
ps: 如有錯誤還望指正
部落格原文地址:HTTP快取——304與200 from cache
GayHub:wclimb