HTTP報(bào)頭字段 是 HTTP中請(qǐng)求和響應(yīng)消息的頭部部分的組件。他們是定義HTTP事務(wù)的操作參數(shù)

頭部字段在請(qǐng)求行或者響應(yīng)行發(fā)出之后，才會(huì)被傳送；

首先讓我們以RFC 7230為例了解一下 報(bào)文格式 Message Format:

1、Message Format 報(bào)文格式

RFC 7230     HTTP/1.1 Message Syntax and Routing      June 2014
HTTP-message = start-line
               *( header-field CRLF )(0或多個(gè))
               CRLF（回車(chē)換行表明頭部部分的結(jié)束）
               [ message-body ]

1.1、start-line 開(kāi)始行

start-line = request-line / status-line

一個(gè)HTTP消息可以是客戶端發(fā)往服務(wù)器的一個(gè)request請(qǐng)求也可以是服務(wù)器響應(yīng)客戶端的response響應(yīng)。
這個(gè)兩者的區(qū)別就在于 start-line 是 request-line (針對(duì)請(qǐng)求) 或者 status-line（針對(duì)響應(yīng)）.

在理論上，一個(gè)客戶端可以接收請(qǐng)求和一個(gè)服務(wù)端可以接收響應(yīng)，根據(jù)他們的不同的 start-line.但是在實(shí)踐中
，服務(wù)器是被用來(lái)實(shí)現(xiàn)只希望接收一個(gè)請(qǐng)求（響應(yīng)是作為一個(gè)未知名或者不合法的請(qǐng)求的一個(gè)解釋?zhuān)┖涂蛻舳耸菍?shí)現(xiàn)只接受響應(yīng)的。

1.2、request-line 請(qǐng)求行

request-line = method SP(空格) request-target SP HTTP-version CRLF(回車(chē)換行)

method token 表明請(qǐng)求資源的請(qǐng)求方法，大小寫(xiě)敏感：

+---------+-------------------------------------------------+-------+
   | Method  | Description                                     | Sec.  |
   +---------+-------------------------------------------------+-------+
   | GET     | Transfer a current representation of the target | 4.3.1 |
   |         | resource.                                       |       |
   |         | 傳輸目標(biāo)資源的當(dāng)前表示                              |       |
   | HEAD    | Same as GET, but only transfer the status line  | 4.3.2 |
   |         | and header section.                             |       |
   |         | 只傳輸狀態(tài)行和頭部                                 |       |
   | POST    | Perform resource-specific processing on the     | 4.3.3 |
   |         | request payload.                                |       |
   |         | 請(qǐng)求負(fù)載中執(zhí)行指定資源的處理                         |       |
   | PUT     | Replace all current representations of the      | 4.3.4 |
   |         | target resource with the request payload.       |       |
   |         | 在請(qǐng)求負(fù)載中替換目標(biāo)資源的當(dāng)前表示                    |       |
   | DELETE  | Remove all current representations of the       | 4.3.5 |
   |         | target resource.                                |       |
   |         | 移除目標(biāo)資源的所有現(xiàn)在的表示                         |       |
   | CONNECT | Establish a tunnel to the server identified by  | 4.3.6 |
   |         | the target resource.                            |       |
   |         | 目標(biāo)資源定義建立的一個(gè)連接服務(wù)器的通道                 |       |
   | OPTIONS | Describe the communication options for the      | 4.3.7 |
   |         | target resource.                                |       |
   |         | 描述目標(biāo)資源的連接參數(shù)                              |       |
   | TRACE   | Perform a message loop-back test along the path | 4.3.8 |
   |         | to the target resource.                         |       |
   |         | 跟隨目標(biāo)資源執(zhí)行一個(gè)消息回環(huán)測(cè)試                      |       |
   +---------+-------------------------------------------------+-------+

request-target 是當(dāng)前請(qǐng)求要求獲取的資源

接收者會(huì)用空格隔開(kāi)的方式去格式化 request-line 到它的組件里面。不用空格隔開(kāi)的話，只能有三個(gè)組件。
不幸運(yùn)的是，一些用戶代理不能去合理的解壓或者解碼超文本里面發(fā)現(xiàn)的空格。導(dǎo)致了這些不允許的字符被發(fā)送到請(qǐng)求的目標(biāo)那里。

接收者的一個(gè)非法 request-line 應(yīng)該被請(qǐng)求目標(biāo)回應(yīng) 400（bad request）錯(cuò)誤 或者 301（永久移除）；
接收者不應(yīng)該嘗試去自動(dòng)更正然后沒(méi)有重定向地處理這個(gè)請(qǐng)求，因?yàn)榉欠ǖ?reqest-line 會(huì)跟著請(qǐng)求鏈故意精心的繞過(guò)安全過(guò)濾策略。

HTTP并不會(huì)預(yù)先設(shè)置一個(gè)request-line的長(zhǎng)度。服務(wù)器如果接收一個(gè)比其他任何請(qǐng)求都長(zhǎng)的請(qǐng)求的時(shí)候，會(huì)反饋一個(gè) 501 （沒(méi)有實(shí)現(xiàn)）的狀態(tài)碼。一個(gè)服務(wù)器接收一個(gè)比任何URL都長(zhǎng)的請(qǐng)求目標(biāo)是，它希望解析必須回應(yīng)一個(gè) 414 （URL Too long）的狀態(tài)碼。

1.3、status line 狀態(tài)行

status-line = HTTP-version SP status-code SP reason-phrase CRLF

響應(yīng)消息的第一行就是 status-line，由 協(xié)議版本 + SP + statusCode + SP + reason-phrase + CRLF 組成。

status-code = 3DIGIT （三個(gè)數(shù)字）

狀態(tài)碼用來(lái)描述服務(wù)器嘗試?yán)斫夂蜐M足客戶端相應(yīng)請(qǐng)求的結(jié)果。其他的響應(yīng)信息是用來(lái)解釋狀態(tài)碼的定義。
狀態(tài)碼是可以擴(kuò)展的，客戶端不用去理解注冊(cè)的狀態(tài)碼的含義，盡管這樣的理解是明顯令人向往的。
但是客戶端必須懂得這些狀態(tài)碼的分類(lèi)，也就是第一個(gè)數(shù)字，不能把一個(gè)未被認(rèn)可的狀態(tài)碼等價(jià)于 X00, 客戶端不能緩存一個(gè)帶有未知名狀態(tài)碼的響應(yīng)消息。

第一個(gè)數(shù)字代表狀態(tài)碼的分類(lèi)，其他兩個(gè)數(shù)字沒(méi)有明顯的分類(lèi)規(guī)則，總共有5類(lèi)狀態(tài)碼：

1XX (Informational信息)： 請(qǐng)求被接收，持續(xù)處理的過(guò)程。
2XX (Successfull成功): 請(qǐng)求被成功接收，解讀和接受。
3XX (Redirection重定向): 為了完成請(qǐng)求過(guò)程，更多的動(dòng)作需要去執(zhí)行。
4XX (Client error 客戶端錯(cuò)誤): 請(qǐng)求包含錯(cuò)誤的語(yǔ)法或者不能被實(shí)現(xiàn)。
5XX (Server error 服務(wù)器錯(cuò)誤): 服務(wù)器不能實(shí)現(xiàn)一個(gè)顯然合法的請(qǐng)求。

reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

reason-phrase設(shè)計(jì)的最底層目的是為了提供一個(gè)當(dāng)前狀態(tài)碼的文本描述?？蛻舳丝珊雎?。

1.4、Header Fields 頭部字段

每一個(gè)頭部字段由一個(gè)大小寫(xiě)不敏感的字段名字，跟著一個(gè)冒號(hào)，可選的空格，字段值和可選的尾部空格組成。

header-field = field-name  ":" OWS(可選的空格) field-value OWS

         field-name     = token
     field-value    = *( field-content / obs-fold )
     field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
     field-vchar    = VCHAR / obs-text

     obs-fold       = CRLF 1*( SP / HTAB )
                    ; obsolete line folding
                    

1.5、message body

 message-body = *OCTET
 
一個(gè)HTTP消息的消息正文是用來(lái)攜帶請(qǐng)求或者響應(yīng)的負(fù)載正文。
消息體是和有效載荷體是一致的，除非一個(gè)傳輸編碼已經(jīng)被完成。

消息中允許的消息主體的規(guī)則在請(qǐng)求和響應(yīng)中是不同的。

request 請(qǐng)求中的 message body的預(yù)定義是被 Content-Length 或 Transfer-Encoding 頭部字段控制。

請(qǐng)求消息框架是和method的語(yǔ)義無(wú)關(guān)的。甚至請(qǐng)求方法對(duì)消息體沒(méi)有任何用處。

響應(yīng)消息中的message body存在與否決定于請(qǐng)求的方法和響應(yīng)返回的狀態(tài)碼。
HEAD請(qǐng)求不會(huì)返回 message body，因?yàn)樗皇顷P(guān)聯(lián)響應(yīng)頭部字段。即使存在 message body ，如果方法是GET也是表明將會(huì)顯示什么值.
所有 1XX 204 304 都不會(huì)有 message body.

2、Standard request fields 標(biāo)準(zhǔn)請(qǐng)求頭字段