1. 程式人生 > >HTTP請求返回304狀態碼

HTTP請求返回304狀態碼

轉自:https://blog.csdn.net/itpinpai/article/details/48181849

大家好,今天給大家分享一個狀態碼304,大家可能在以前的開發中開啟chrome tools 或 firebug工具時有意間或無意間看到它。

HTTP 304: Not Modified 
標準解釋是:Not Modified 客戶端有緩衝的文件併發出了一個條件性的請求(一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文件)。伺服器告訴客戶,原來緩衝的文件還可以繼續使用。
如下圖:

在請求頭裡有:If-Modified-Since: Mon, 17 Aug 2015 01:53:41 GMT

在響應頭裡有:Last-Modified: Mon, 17 Aug 2015 01:53:41 GMT

大家對比一下這二個日期發日期和時分秒都是完全一致的,如果一致就從快取中去獲取內容

我們在圖片中看到了一個它cache-control 
如果cache-control:no-chache說明強制每次請求直接傳送給源伺服器,而不經過本地快取版本的校驗。
如果cache-control:max-age=0有二種情況:
1、max-age>0 時 直接從遊覽器快取中 提取 
2、max-age<=0 時 向server 傳送http 請求確認 ,該資源是否有修改有的話 返回200 ,無的話 返回304. 

第一次訪問 200 
滑鼠點選二次訪問 (Cache) 
按F5重新整理 304 
按Ctrl+F5強制重新整理 200

===========================================================================================

轉自:https://blog.csdn.net/canot/article/details/76359917

最近研究nginx日誌的時候,對於304這個狀態碼產生了好奇。之前一直知道3XX系列的狀態碼錶示重定向,但對於304的具體原理沒有仔細研究過。

304 的標準解釋是:客戶端有緩衝的文件併發出了一個條件性的請求。伺服器告訴客戶端,原來緩衝的文件還可以繼續使用。

完成這個幾個動作包括伺服器確認返回304給予客戶端,主要包含幾個http頭資訊,請求頭If-None-Match、響應頭ETag和響應頭Cache-Control

為了更好的理解304狀態碼以及快取,直接實驗一把: 
為了方便就使用express啟動一個服務了(express幾行程式碼就搞定了)

var express = require('express');
var app = express();

app.get('/', function(req, res) {
  res.send('hello world');
});
app.listen('8080')

啟動之後,瀏覽器訪問localhost:8080並觀察請求,響應頭。

第一次請求: 

è¿éåå¾çæè¿°

第二次請求: 

è¿éåå¾çæè¿°

第二次請求伺服器返回了一個304。

在第一次請求伺服器的時候在獲取資源之後是會先把該資源快取在本地的,同時伺服器response返回了一個響應頭ETag,ETag全稱Entity Tag,用來標識一個資源。在具體的實現中,ETag可以是資源的hash值,也可以是一個內部維護的版本號。但不管怎樣,ETag應該能反映出資源內容的變化,這是Http快取可以正常工作的基礎。伺服器對於hello world這個字串使用上述返回的ETag來表示,只要hello world這個資源不變,這個Etag就不會變。

客戶端第二次請求伺服器的時候,利用請求頭If-None-Match來告訴伺服器自己已經有個ETag為xxx的資源。如果伺服器上的資源沒有變化,也就是說伺服器上的資源的ETag也是xxx的話,伺服器就不會再返回該資源的內容,而是返回一個304的響應,告訴瀏覽器該資源沒有變化,快取有效,瀏覽器將直接呼叫本地快取。

響應頭Cache-Control

每個資源都可以通過Http頭Cache-Control來定義自己的快取策略,Cache-Control控制誰在什麼條件下可以快取響應以及可以快取多久。 最快的請求是不必與伺服器進行通訊的請求:通過響應的本地副本,我們可以避免所有的網路延遲以及資料傳輸的資料成本。為此,HTTP 規範允許伺服器返回一系列不同的 Cache-Control 指令,控制瀏覽器或者其他中繼快取如何快取某個響應以及快取多長時間。

Cache-Control 頭在 HTTP/1.1 規範中定義,取代了之前用來定義響應快取策略的頭(例如 Expires)。當前的所有瀏覽器都支援 Cache-Control,因此,使用它就夠了。

以下我來介紹可以再Cache-Control中設定的常用指令。

max-age 

該指令指定從當前請求開始,允許獲取的響應被重用的最長時間(單位為秒。例如:Cache-Control:max-age=60表示響應可以再快取和重用 60 秒。需要注意的是,在max-age指定的時間之內,瀏覽器不會向伺服器傳送任何請求,包括驗證快取是否有效的請求,也就是說,如果在這段時間之內,伺服器上的資源發生了變化,那麼瀏覽器將不能得到通知,而使用老版本的資源。所以在設定快取時間的長度時,需要慎重。

public和private

如果設定了public,表示該響應可以再瀏覽器或者任何中繼的Web代理中快取,public是預設值,即Cache-Control:max-age=60等同於Cache-Control:public, max-age=60。

在伺服器設定了private比如Cache-Control:private, max-age=60的情況下,表示只有使用者的瀏覽器可以快取private響應,不允許任何中繼Web代理對其進行快取 - 例如,使用者瀏覽器可以快取包含使用者私人資訊的 HTML 網頁,但是 CDN 不能快取。

no-cache

如果伺服器在響應中設定了no-cache即Cache-Control:no-cache,那麼瀏覽器在使用快取的資源之前,必須先與伺服器確認返回的響應是否被更改,如果資源未被更改,可以避免下載。這個驗證之前的響應是否被修改,就是通過上面介紹的請求頭If-None-match和響應頭ETag來實現的。

需要注意的是,no-cache這個名字有一點誤導。設定了no-cache之後,並不是說瀏覽器就不再快取資料,只是瀏覽器在使用快取資料時,需要先確認一下資料是否還跟伺服器保持一致。如果設定了no-cache,而ETag的實現沒有反應出資源的變化,那就會導致瀏覽器的快取資料一直得不到更新的情況。

no-store

如果伺服器在響應中設定了no-store即Cache-Control:no-store,那麼瀏覽器和任何中繼的Web代理,都不會儲存這次相應的資料。當下次請求該資源時,瀏覽器只能重新請求伺服器,重新從伺服器讀取資源。