http協議是前端開發人員最常接觸到的網絡協議。在開發過程中，尤其是調試過程中避免不了需要去分析http請求的詳細信息。在這其中頭部字段提供的信息最多，比如通過響應狀態碼我們可以直觀的看到響應的大致狀態。那么你是否清楚http首部字段都有哪些，具體含義是什么，可選值又有哪些呢？看完下面的內容，我相信對於這幾個問題你就會迎刃而解。
http協議用於交互的信息被稱為HTTP報文。請求端（客戶端）的HTTP報文叫做請求報文，響應端（服務器端）的HTTP報文叫做響應報文。HTTP報文大致可以分為報文首部和報文主題兩部分。我們來看下請求報文和響應報文的結構。
從上圖我們可以看出，請求報文和響應報文的首部內容由以下數據組成。
請求行
包含用於請求的方法，請求 URI 和 HTTP 版本。
狀態行
包含表明響應結果的狀態碼，原因短語和 HTTP 版本。
首部字段
包含表示請求和響應的各種條件和屬性的各類首部。
下面我們重點來看下首部字段的一些信息，並且對最常用到的首部字段的含義及可選值都有哪些，分別代表什么意思進行講解。
http首部字段類型根據實際用途被分為以下4種類型：
通用首部字段（General Header Fields）
請求報文和響應報文兩方都會使用的首部。
請求首部報文（Request Headers Fields）
從客戶端向服務端發送請求報文時使用的首部。補充了請求的附加內容，客戶端信息，響應內容相關優先級等信息。
響應首部字段（Response Header Fields）
從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
實體首部字段（Entity Header Fields）
針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體相關的信息。
其中http/1.1規范定義了47種首部字段，下面我們按照以上的四個大類對這47種字段進行一個簡要解釋：
通用首部字段
| 首部字段名 | 說明 |
|---|---|
| Cache-Control | 控制緩存的行為 |
| Connection | 連接的管理 |
| Date | 創建報文的日期時間 |
| Pragma | 報文指令 |
| Trailer | 報文末端的首部一覽 |
| Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
| Upgrade | 升級為其他協議 |
| Via | 代理服務器的相關信息 |
| Warning | 錯誤通知 |
請求首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優先的字符集 |
| Accept-Encoding | 優先的內容編碼 |
| Accept-Language | 優先的語言（自然語言） |
| Authorization | Web認證信息 |
| Expect | 期待服務器的特定行為 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在服務器 |
| If-Match | 比較實體標記（ETag） |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實體標記（與 If-Match 相反） |
| If-Range | 資源未更新時發送實體 Byte 的范圍請求 |
| If-Unmodified-Since | 比較資源的更新時間（與If-Modified-Since相反） |
| Max-Forwards | 最大傳輸逐跳數 |
| Proxy-Authorization | 代理服務器要求客戶端的認證信息 |
| Range | 實體的字節范圍請求 |
| Referer | 對請求中URI的原始獲取方 |
| TE | 傳輸編碼的優先級 |
| User-Agent | HTTP客戶端程序的信息 |
響應首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節范圍請求 |
| Age | 推算資源創建經過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定URI |
| Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
| Retry-After | 對再次發起請求的時機要求 |
| Server | HTTP服務器的安裝信息 |
| Vary | 代理服務器緩存的管理信息 |
| WWW-Authenticate | 服務器對客戶端的認證信息 |
實體首部字段
| 首部字段名 | 說明 |
|---|---|
| Allow | 資源可支持的HTTP方法 |
| Content-Encoding | 實體主體適用的編碼方式 |
| Content-Language | 實體主體的自然語言 |
| Content-Length | 實體主體的大小（單位：字節） |
| Content-Location | 替代對應資源的URI |
| Content-MD5 | 實體主體的報文摘要 |
| Content-Range | 實體主體的位置范圍 |
| Content-Type | 實體主體的媒體類型 |
| Expires | 實體主體過期的日期時間 |
| Last-Modified | 資源的最后修改日期時間 |
常用首部字段分析：
1. Cache-Control 指令一覽
可用的指令按請求和響應分類如下所示：
緩存請求指令：
| 指令 | 參數 | 說明 |
|---|---|---|
| no-cache | 無 | 強制向原服務器再次驗證 |
| no-store | 無 | 不緩存請求或響應的任何內容 |
| max-age = [ 秒] | 必須 | 響應的最大Age值 |
| max-stale( = [ 秒]) | 可省略 | 接收已過期的響應 |
| min-fresh = [ 秒] | 必需 | 期望在指定的時間內的響應仍有效 |
| no-transform | 無 | 代理不可更改媒體類型 |
| only-if-cached | 無 | 代理不可更改媒體類型 |
| cache-extension | - | 新指令標記（token） |
緩存響應指令：
| 指令 | 參數 | 說明 |
|---|---|---|
| public | 無 | 可向任意方提供響應的緩存 |
| private | 可省略 | 僅向特定用戶返回響應 |
| no-cache | 可省略 | 緩存前必需先確認其有效性 |
| no-store | 無 | 不緩存請求或響應的任何內容 |
| no-transform | 無 | 代理不可更改媒體類型 |
| must-revalidate | 無 | 可緩存但必須再向源服務器進行確認 |
| proxy-revalidate | 無 | 要求中間緩存服務器對緩存的響應有效性再進行確認 |
| max-age=[秒] | 必需 | 響應的最大Age值 |
| s-maxage=[秒] | 必需 | 公共緩存服務器響應的最大Age值 |
| cache-extension | - | 新指令標記（token） |
從字面意思上很容易把 no-cache 誤解成為不緩存，但事實上 no-cache 代表不緩
存過期的資源，緩存會向源服務器進行有效期確認后處理資源，也許稱為 do-notserve-
from-cache-without-revalidation 更合適。no-store 才是真正地不進行緩存，請
讀者注意區別理解
2. Connection
Connection首部字段具備如下兩個作用
- 控制不再轉發給代理的首部字段
- 管理持久連接
HTTP/1.1 版本的默認連接都是持久連接。為此，客戶端會在持
久連接上連續發送請求。當服務器端想明確斷開連接時，則指定
Connection 首部字段的值為 Close。
Date
首部字段Date表明創建HTTP報文的日期和時間。
3. Pragma
Pragma是HTTP/1.1之前版本的歷史遺留字段，僅作為與HTTP/1.0的向后兼容而定義。
規范定義的形式唯一，如下所示：
| Pragma: no-cache |
|---|
該首部字段屬於通用首部字段，但只用在客戶端發送的請求中。客戶端會要求所有的中間服務器不返回緩存的資源。
所有的中間服務器如果都能以 HTTP/1.1 為基准，那直接采用 Cache-
Control: no-cache 指定緩存的處理方式是最為理想的。但要整體掌握
全部中間服務器使用的 HTTP 協議版本卻是不現實的。因此，發送的
請求會同時含有下面兩個首部字段。
Cache-Control: no-cache
Pragma: no-cache
4. Upgrade
首部字段 Upgrade 用於檢測 HTTP 協議及其他協議是否可使用更高的
版本進行通信，其參數值可以用來指定一個完全不同的通信協議。
使用首部字段 Upgrade 時，還需要額外指定Connection:Upgrade。
5. Accept
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept 首部字段可通知服務器，用戶代理能夠處理的媒體類型及媒體
類型的相對優先級。可使用 type/subtype 這種形式，一次指定多種媒
體類型。
6. Accept-Charset
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Accept-Charset 首部字段可用來通知服務器用戶代理支持的字符集及
字符集的相對優先順序。另外，可一次性指定多種字符集。與首部字
段 Accept 相同的是可用權重 q 值來表示相對優先級
7. Accept-Encoding
Accept-Encoding: gzip, deflate
Accept-Encoding 首部字段用來告知服務器用戶代理支持的內容編碼及
內容編碼的優先級順序。可一次性指定多種內容編碼。
下面試舉出幾個內容編碼的例子。
- gzip
由文件壓縮程序 gzip（GNU zip）生成的編碼格式
（RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循環冗余
校驗（Cyclic Redundancy Check，通稱 CRC）。
- compress
由 UNIX 文件壓縮程序 compress 生成的編碼格式，采用 Lempel-
Ziv-Welch 算法（LZW）。
- deflate
組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法
（RFC1951）生成的編碼格式。
- identity
不執行壓縮或不會變化的默認編碼格式
采用權重 q 值來表示相對優先級，這點與首部字段 Accept 相同。另
外，也可使用星號（*）作為通配符，指定任意的編碼格式。
8. Accept-Language
Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3
首部字段 Accept-Language 用來告知服務器用戶代理能夠處理的自然
語言集（指中文或英文等），以及自然語言集的相對優先級。可一次
指定多種自然語言集。
和 Accept 首部字段一樣，按權重值 q 來表示相對優先級。在上述圖
例中，客戶端在服務器有中文版資源的情況下，會請求其返回中文版
對應的響應，沒有中文版時，則請求返回英文版響應。
9. If-Match
形如 If-xxx 這種樣式的請求首部字段，都可稱為條件請求。服務器接
收到附帶條件的請求后，只有判斷指定條件為真時，才會執行請求。
首部字段 If-Match，屬附帶條件之一，它會告知服務器匹配資源所用
的實體標記（ETag）值。這時的服務器無法使用弱 ETag 值。（請參
照本章有關首部字段 ETag 的說明）
服務器會比對 If-Match 的字段值和資源的 ETag 值，僅當兩者一致
時，才會執行請求。反之，則返回狀態碼 412 Precondition Failed 的響
應。
還可以使用星號（*）指定 If-Match 的字段值。針對這種情況，服務
器將會忽略 ETag 的值，只要資源存在就處理請求。
10. Referer
Referer: http://172.30.1.34:4200/
首部字段 Referer 會告知服務器請求的原始資源的 URI。
11. User-Agent
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36
首部字段 User-Agent 會將創建請求的瀏覽器和用戶代理名稱等信息傳
達給服務器。
12. Age
首部字段 Age 能告知客戶端，源服務器在多久前創建了響應。字段值
的單位為秒。
若創建該響應的服務器是緩存服務器，Age 值是指緩存后的響應再次
發起認證到認證完成的時間值。代理創建響應時必須加上首部字段
Age。
13. ETag
首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串
形式做唯一性標識的方式。服務器會為每份資源分配對應的 ETag
值。
14. Location
使用首部字段 Location 可以將響應接收方引導至某個與請求 URI 位置
不同的資源。
基本上，該字段會配合 3xx ：Redirection 的響應，提供重定向的
URI。
幾乎所有的瀏覽器在接收到包含首部字段 Location 的響應后，都會強
制性地嘗試對已提示的重定向資源的訪問。
15. Content-Encoding
首部字段 Content-Encoding 會告知客戶端服務器對實體的主體部分選
用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行
的壓縮。
16. Content-Language
Content-Language: zh-CN
首部字段 Content-Language 會告知客戶端，實體主體使用的自然語言
（指中文或英文等語言）。
17. Content-Length
Content-Length: 15000
首部字段 Content-Length 表明了實體主體部分的大小（單位是字
節）。對實體主體進行內容編碼傳輸時，不能再使用 Content-Length
首部字段
18. Content-Type
Content-Type: text/html; charset=UTF-8
首部字段 Content-Type 說明了實體主體內對象的媒體類型。和首部字
段 Accept 一樣，字段值用 type/subtype 形式賦值。
19. Last-Modified
Last-Modified: Wed, 21 Aug 2019 06:18:22 GMT
首部字段 Last-Modified 指明資源最終修改的時間。一般來說，這個
值就是 Request-URI 指定資源被修改的時間。但類似使用 CGI 腳本進
行動態數據處理時，該值有可能會變成數據最終修改時的時間。
20. Set-Cookie
Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31
服務器設置客戶端cookie信息，以便管理客戶端狀態。
-
HttpOnly 屬性
Cookie 的 HttpOnly 屬性是 Cookie 的擴展功能，它使 JavaScript 腳本
無法獲得 Cookie。其主要目的為防止跨站腳本攻擊（Cross-site
scripting，XSS）對 Cookie 的信息竊取。
發送指定 HttpOnly 屬性的 Cookie 的方法如下所示。
Set-Cookie: name=value; HttpOnly
通過上述設置，通常從 Web 頁面內還可以對 Cookie 進行讀取操作。
但使用 JavaScript 的 document.cookie 就無法讀取附加 HttpOnly 屬性后
的 Cookie 的內容了。因此，也就無法在 XSS 中利用 JavaScript 劫持
Cookie 了。
以上所列出的首部字段都是基於HTTP/1.1，到這里本文要介紹的相關知識也就結束了。對於文章開頭提出的三個問題不知道你現在有沒有清楚呢。最后希望小伙伴可以在下方留言評論（對於文章的文字排版，寫作技巧，相關內容都可以相互交流學習）