HTTP首部字段徹底解析

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首部字段具有以下兩個做用

1. 控制再也不轉發給代理的首部字段
2. 管理持久鏈接

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，到這裏本文要介紹的相關知識也就結束了。對於文章開頭提出的三個問題不知道你如今有沒有清楚呢。最後但願小夥伴能夠在下方留言評論（對於文章的文字排版，寫做技巧，相關內容均可以相互交流學習）

原文出處：https://www.cnblogs.com/xzsty/p/11452610.html