狀態碼200：請求已成功，請求所希望的響應頭或資料體將隨此響應返回，即返回的資料為全量的資料，如果檔案不通過gzip壓縮的話，檔案是多大，則要有多大傳輸量，出現此狀態碼是表示正常狀態。
狀態碼304：如果客戶端傳送了乙個帶條件的 get 請求且該請求已被允許，而文件的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則伺服器應當返回這個狀態碼。客戶端和伺服器端只需要傳輸很少的資料量來做檔案的校驗，如果檔案沒有修改過，則不需要返回全量的資料。
該響應必須包含以下的頭資訊：
date，除非這個伺服器沒有時鐘。假如沒有時鐘的伺服器也遵守這些規則，那麼**伺服器以及客戶端可以自行將 date 字段新增到接收到的響應頭中去（正如rfc 2068中規定的一樣），快取機制將會正常工作。
etag 和/或 content-location，假如同樣的請求本應返回200響應。
expires, cache-control，和/或vary，假如其值可能與之前相同變數的其他響應對應的值不同的話。
舉例說明：
在一般情況下，瀏覽器在發請求前，快取了某個檔案，就先把自己快取的檔案資訊放在請求頭里，向伺服器發起get請求
伺服器收到請求後，在給瀏覽器傳送響應前，對比一下這個檔案資訊，發現瀏覽器快取的檔案就是它，於是決定不傳送整個檔案內容，直接告訴瀏覽器 304 。
瀏覽器接收到 304 時，就知道原來我快取的就是跟伺服器端一樣的檔案，於是就直接拿本地快取來用了。
如果伺服器發現瀏覽器的快取檔案資訊已經是舊的了，伺服器就直接正常的傳送檔案內容，瀏覽器正常的接收檔案內容
HTTP 狀態碼 304 快取機制
客戶端第一次請求服務端的某個位址時，服務端會在響應時攜帶 etag 與 last modified 響應頭，客戶端下次再傳送同一位址的請求時，會攜帶 if none match 與 if modified since 請求頭，而if none match 就是 etag 的值，if modified...
HTTP狀態碼304快取機制
客戶端第一次請求服務端的某個位址時，服務端會在響應時攜帶 etag 與 last modified 響應頭，客戶端下次再傳送同一位址的請求時，會攜帶 if none match 與 if modified since 請求頭，而if none match 就是 etag 的值，if modified...
http快取機制之304狀態碼
在網上看到一篇關於解釋瀏覽器快取更新機制304狀態碼的文章，裡面說如果請求頭中的if modified since欄位和if none match欄位的值分別和響應頭中的last modified欄位和etag字段值一致，伺服器就會返回304狀態碼 無響應體 瀏覽器就從本地讀取快取資料。但實際上，伺...