HTTP首部欄位詳解
在HTTP/1.1規範中定義了47種首部欄位，總共分為四大類：
- 通用首部欄位 —— 請求報文和響應報文兩方都會使用的首部
- 請求首部欄位 —— 從客戶端向伺服器端傳送請求報文時使用的首部。補充了
請求的附加內容、客戶端資訊、響應內容相關優先順序等資訊 - 響應首部欄位 —— 從伺服器端向客戶端返回響應報文時使用的首部。補充了
響應的附加內容，也會要求客戶端附加額外的內容資訊 - 實體首部欄位 —— 針對
請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的資訊
通用首部欄位
Cache-Control
通過多個可選的指令引數實現對快取伺服器的快取行為的控制。
Cache-Control指令可用於請求及響應時，因此Cache-Control指令可分為請求指令和響應指令。
快取請求指令
no-cache —— 防止從快取中返回過期的資源。
- 從客戶端的角度來說，如果傳送的請求中包含no-cache指令，則表示客戶端不會接收快取過的響應。所以，後續的請求都要求快取伺服器把客戶端請求轉發給源伺服器。
- 從伺服器的角度來說，如果伺服器返回的響應中包含no-cache指令，那麼快取伺服器不能對資源進行快取。源伺服器以後也將不再對快取伺服器請求中提出的資源有效性進行確認，且禁止其對響應資源進行快取操作。
no-store —— 真正意義上的不快取，該指令規定快取不能在本地儲存請求或響應的任一部分。
max-age —— 代表資源儲存為快取的最長時間
- 從客戶端的角度，當客戶端傳送的請求中包含max-age指令時，如果判定快取伺服器上的快取資源的快取時間數值比指定時間的數值更小，那麼客戶端就接收快取資源。當max-age值為0時，快取伺服器通常需要將請求轉發給源伺服器。
- 從服務端的角度，當伺服器返回的響應中包含 max-age 指令時，快取伺服器將不對資源的有效性再作確認，在max-age時間內可直接支配快取。
min-fresh —— 要求快取伺服器返回至少還未過指定時間的快取資源，即指定時間內仍不會過期的快取資源。
快取響應指令
public —— 表明是共享快取，其他使用者也可使用該快取
private —— 獨佔快取，伺服器的響應只以特定的使用者作為物件，快取伺服器會對該特定使用者提供資源快取的服務，對於其他使用者傳送過來的請求，代理伺服器則不會返回快取。
must-revalidate —— 代理會向源伺服器再次驗證即將返回的響應快取目前是否仍然有效。
proxy-revalidate —— 要求所有的快取伺服器在接收到客戶端帶有該指令的請求返回響應之前，必須再次驗證快取的有效性。
Connection
兩個作用：
-
控制
不再轉發給代理的首部欄位
-
管理持久連線
HTTP/1.1版本的
預設連線就是持久連線。因此，客戶端會在持久連線上連續傳送請求。 當伺服器端想明確斷開連線時，則指定Connection首部欄位的值為 Close。另外，如果想在舊版本的HTTP協議上維持持久連線，則需要指定Connection首部欄位的值為
Keep-Alive。
Date
表明建立HTTP報文的日期和時間。有兩種格式：
-
HTTP/1.1採用RFC1123中規定的格式
-
之前的版本使用RFC850中規定的格式
Transfer-Encoding
規定了傳輸報文主體時採用的編碼方式。
ps: HTTP/1.1的傳輸編碼方式僅對分塊傳輸編碼有效。
正如上面的響應報文在首部欄位 Transfer-Encoding 中指定的那樣，有效使用分塊傳輸編碼，且分別被分成 3312 位元組和 914 位元組大小的分塊資料。
Upgrade
用於檢測 HTTP 協議及其他協議是否可使用更高的版本進行通訊，其引數值可以用來指定一個完全不同的通訊協議。例如下圖，僅作用在客戶端和鄰接伺服器之間的請求中的Upgrade欄位指定的值為TLS/1.0，鄰接伺服器的響應中的Upgrade欄位值為TLS/1.0和HTTP/1.1。
Via
追蹤客戶端與伺服器之間的請求和響應報文的傳輸路徑，簡單來說就是追蹤報文的轉發，避免請求迴環的發生。報文經過代理或閘道器時，會先在首部欄位 Via 中附加該伺服器的資訊，然後再進行轉發。
Via 首部是為了追蹤傳輸路徑，所以經常會和 TRACE請求方法一起使用。
Warning
通常會告知使用者一些與快取相關的問題的警告。
請求首部欄位
內容協商
Accept
通知伺服器，使用者代理能夠處理的媒體型別及媒體型別的相對優先順序。 可使用 type/subtype 這種形式，一次指定多種媒體型別（MIME型別）。
MIME型別資料
MIME型別一般會和屬性q一起使用，q表示的是權重，沒使用屬性q則預設權重為1.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
上面的Accept標頭內容對應如下表格：
| q | MIME |
|---|---|
| 1.0 | text/html |
| 1.0 | application/xhtml+xml |
| 0.9 | application/xml |
| 0.8 | / |
Accept-Charset
客戶端能接受的字元編碼。
Accept-Encoding
希望服務端返回的內容編碼，通常是一種壓縮演算法，同樣採用權重 q 值來表示採用壓縮演算法的相對優先順序。
- gzip —— 由檔案壓縮程式 gzip（GNU zip）生成的編碼格式（RFC1952）， 採用 Lempel-Ziv 演算法（LZ77）及 32 位迴圈冗餘校驗（Cyclic Redundancy Check，通稱 CRC）。
- compress —— UNIX 檔案壓縮程式 compress 生成的編碼格式，採用 LempelZiv-Welch 演算法（LZW）。
- deflate —— 組合使用 zlib 格式（RFC1950）及由 deflate 壓縮演算法（RFC1951） 生成的編碼格式。
- identity —— 不執行壓縮或不會變化的預設編碼格式。
Accept-Language
客戶端需要服務端返回的語言型別，同樣採用權重 q 值來表示希望接收的自然語言類別的相對優先順序。
授權
Authorization
首部欄位 Authorization 是用來告知伺服器，使用者代理的認證資訊（證書值）。通常，想要通過伺服器認證的使用者代理會在接收到返回的 401 狀態碼響應後，把首部欄位 Authorization 加入請求中。
通訊資訊
From
告知伺服器使用使用者代理的使用者的電子郵件地址。
Host
告知伺服器，請求的資源所處的網際網路主機名和埠號。Host 首部欄位在 HTTP/1.1 規範內是唯一一個必須被包含在請求內的首部欄位。
Host欄位的存在意義—— 通常單臺伺服器會分配多個域名的虛擬主機，Host欄位能幫助區分虛擬主機。
User-Agent
建立請求的瀏覽器和使用者代理名稱等資訊傳達給伺服器。
附加條件請求
形如 If-xxx 這種樣式的請求首部欄位，都可稱為條件請求。伺服器接收到附帶條件的請求後，只有判斷指定條件為真時，才會執行請求。
If-Match
只有當 If-Match 的欄位值跟 ETag 值匹配一致時，伺服器才會接受請求。
還可以使用星號（*）指定 If-Match 的欄位值。針對這種情況，伺服器將會忽略 ETag 的值，只要資源存在就處理請求。
If-Modified-Since
告知伺服器若 If-Modified-Since 欄位值早於資源的更新時間，則希望能處理該請求。而在指定 If-Modified-Since 欄位值的日期時間之後，如果請求的資源都 沒有過更新，則返回狀態碼 304 Not Modified 的響應。
If-Modified-Since 用於確認代理或客戶端擁有的本地資源的有效性。
If-Unmodified-Since
告知伺服器，指定的請求資源只有在欄位值內指定的日期時間之後，未發生更新的情況下，才能處理請求。
If-None-Match
和首部欄位If-Match的作用恰恰相反。當指定 If-None-Match 欄位值的實體標記（ETag） 值與請求資源的 ETag 不一致時，它就告知伺服器處理該請求。因此，在GET或HEAD方法中使用首部欄位If-None-Match可獲取最新的資源。
If-Range
告知伺服器若指定的 If-Range 欄位值（ETag 值或者時間）和請求資源的 ETag 值或時間相一 致時，則作為範圍請求處理。反之，則返回全體資源。
不使用If-Range傳送請求的情況：
伺服器端的資源如果更新，那客戶端持有資源中的一部分也會隨之無效。這時，伺服器會暫且以狀態碼 412 Precondition Failed 作為響應返回，其目的是催促客戶端再次傳送請求。 這樣一來，與使用首部欄位 If-Range 比起來，就需要花費兩倍的功夫。
範圍請求
Range
對於只需獲取部分資源的範圍請求，包含首部欄位 Range 即可告知伺服器資源的指定範圍。下面的示例表示請求獲取從第 5001 位元組至第 10000 位元組的資源。服務端的請求結果有兩種：
- 成功處理該範圍請求 —— 返回206 Partial Content響應和請求要求的相應範圍的資源。
- 無法處理該範圍請求 —— 返回200 OK響應和全部資源。
響應首部欄位
響應首部欄位是由伺服器端向客戶端返回響應報文中所使用的字 段，用於補充響應的附加資訊、伺服器資訊，以及對客戶端的附加要求 等資訊，本文重點介紹以下欄位：
範圍請求的響應
關於HTTP響應狀態碼的詳解請參考前篇HTTP請求方法及響應狀態碼詳解
Accept-Ranges
告知客戶端伺服器是否能處理範圍請求，以指定獲取伺服器端某個部分的資源。
-
能處理範圍請求時，
Accept-Ranges：bytes -
不能處理範圍請求時，
Accept-Ranges：none
快取相關響應
Age
告知客戶端，源伺服器在多久前建立了響應。欄位值的單位為秒。
響應實體相關
ETag
告知客戶端實體標識。它是一種可將資源以字串形式做唯一性標識的方式。伺服器會為每份資源分配對應的 ETag 值。 另外，當資源更新時，ETag 值也需要更新。
強ETag vs 弱ETag值
- 強ETag值 —— 不論實體發生多麼細微的變化都會改變其值。
- 弱ETag值 —— 只用於提示資源是否相同。只有資源發生了根本改變，產生差異時才會改變 ETag 值。這時，會在欄位值最開始處附加 W/。
資源定位相關
Location
將響應接收方引導至某個與請求 URI 位置不同的資源。
基本上，該欄位會配合 3xx ：Redirection 的響應，提供重定向的 URI。
幾乎所有的瀏覽器在接收到包含首部欄位 Location 的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。
實體首部欄位
實體首部欄位是包含在請求報文和響應報文中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的資訊。
資源支援的HTTP請求方法
Allow
通知客戶端能夠支援 Request-URI 指定資源的所有 HTTP 方法。
當伺服器接收到不支援的 HTTP 方法時，會以狀態碼405 Method Not Allowed作為響應返回。與此同時，還會把所有能支援 的 HTTP 方法寫入首部欄位 Allow 後返回。
實體主體相關
Content-Encoding
告知客戶端伺服器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體資訊的前提下所進行的壓縮。常用的壓縮方法有gzip、compress、deflate、identity。
Content-Language
告知客戶端，實體主體使用的自然語言（指中文或英文等語言）。
Content-Length
表明了實體主體部分的大小（單位是位元組）。
Content-Location
和 首部欄位 Location 不同，Content-Location 表示的是報文主體返回資源對應的URI。
Content-MD5
首部欄位 Content-MD5 是一串由 MD5 演算法生成的值，其目的在於檢查報文主體在傳輸過程中是否保持完整，以及確認傳輸到達。
ps: 內容如果能夠被篡改，那麼同時意味 著 Content-MD5 也可重新計算然後被篡改。所以處在接收階段的客戶端 是無法意識到報文主體以及首部欄位 Content-MD5 是已經被篡改過的。
Content-Range
針對範圍請求，返回響應時使用的首部欄位 Content-Range，能告知客戶端作為響應返回的實體的哪個部分符合範圍請求。
Content-Type
說明了實體主體內物件的媒體型別。和首部 欄位 Accept 一樣，欄位值用 type/subtype 形式賦值。 引數 charset 使用 iso-8859-1 或 euc-jp 等字符集進行賦值。
資源時效相關
Expires
將資源失效的日期告知客戶端。快取伺服器在接收到含有首部欄位 Expires 的響應後，會以快取來應答請求。在Expires 欄位值指定的時間之前，響應的副本會一直被儲存。當超過指定的時間後，快取伺服器在請求傳送過來時，會轉向源伺服器請求資源。
ps：當首部欄位 Cache-Control 有指定 max-age 指令時，比起首 部欄位 Expires，會優先處理 max-age 指令。
Last-Modified
指明資源最終修改的時間。
為Cookie服務的首部欄位
Set-Cookie
伺服器賦予客戶端的Cookie的屬性設定：
- NAME=VALUE —— 賦予Cookie名稱和值（必需項）
- expires=DATE —— Cookie有效期
- path=PATH —— 將伺服器上的檔案目錄作為Cookie的適用物件
- domain=域名 —— 作為Cookie適用物件的域名
- Secure —— 僅在HTTPS安全通訊時才傳送Cookie
- HttpOnly —— 加以限制，使Cookie不能被JS指令碼訪問
Cookie
當客戶端想獲得 HTTP 狀態管理 支援時，就會在請求中包含從伺服器接收到的Cookie。
參考資料
《圖解HTTP》 by 上野宣