HTTP報頭字段 是 HTTP中請求和響應(yīng)消息的頭部部分的組件。他們是定義HTTP事務(wù)的操作參數(shù)
頭部字段在請求行或者響應(yīng)行發(fā)出之后，才會被傳送；
首先讓我們以RFC 7230為例了解一下 報文格式 Message Format:
1、Message Format 報文格式
RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
HTTP-message = start-line
*( header-field CRLF )(0或多個)
CRLF（回車換行表明頭部部分的結(jié)束）
[ message-body ]
1.1、start-line 開始行
start-line = request-line / status-line
一個HTTP消息可以是客戶端發(fā)往服務(wù)器的一個request請求也可以是服務(wù)器響應(yīng)客戶端的response響應(yīng)。
這個兩者的區(qū)別就在于 start-line 是 request-line (針對請求) 或者 status-line（針對響應(yīng)）.
在理論上，一個客戶端可以接收請求和一個服務(wù)端可以接收響應(yīng)，根據(jù)他們的不同的 start-line.但是在實踐中
，服務(wù)器是被用來實現(xiàn)只希望接收一個請求（響應(yīng)是作為一個未知名或者不合法的請求的一個解釋）和客戶端是實現(xiàn)只接受響應(yīng)的。
1.2、request-line 請求行
request-line = method SP(空格) request-target SP HTTP-version CRLF(回車換行)
method token 表明請求資源的請求方法，大小寫敏感：
+---------+-------------------------------------------------+-------+
| 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. | |
| | 請求負載中執(zhí)行指定資源的處理 | |
| PUT | Replace all current representations of the | 4.3.4 |
| | target resource with the request payload. | |
| | 在請求負載中替換目標(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)資源定義建立的一個連接服務(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í)行一個消息回環(huán)測試 | |
+---------+-------------------------------------------------+-------+
request-target 是當(dāng)前請求要求獲取的資源
接收者會用空格隔開的方式去格式化 request-line 到它的組件里面。不用空格隔開的話，只能有三個組件。
不幸運的是，一些用戶代理不能去合理的解壓或者解碼超文本里面發(fā)現(xiàn)的空格。導(dǎo)致了這些不允許的字符被發(fā)送到請求的目標(biāo)那里。
接收者的一個非法 request-line 應(yīng)該被請求目標(biāo)回應(yīng) 400（bad request）錯誤 或者 301（永久移除）；
接收者不應(yīng)該嘗試去自動更正然后沒有重定向地處理這個請求，因為非法的 reqest-line 會跟著請求鏈故意精心的繞過安全過濾策略。
HTTP并不會預(yù)先設(shè)置一個request-line的長度。服務(wù)器如果接收一個比其他任何請求都長的請求的時候，會反饋一個 501 （沒有實現(xiàn)）的狀態(tài)碼。一個服務(wù)器接收一個比任何URL都長的請求目標(biāo)是，它希望解析必須回應(yīng)一個 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 （三個數(shù)字）
狀態(tài)碼用來描述服務(wù)器嘗試理解和滿足客戶端相應(yīng)請求的結(jié)果。其他的響應(yīng)信息是用來解釋狀態(tài)碼的定義。
狀態(tài)碼是可以擴展的，客戶端不用去理解注冊的狀態(tài)碼的含義，盡管這樣的理解是明顯令人向往的。
但是客戶端必須懂得這些狀態(tài)碼的分類，也就是第一個數(shù)字，不能把一個未被認可的狀態(tài)碼等價于 X00, 客戶端不能緩存一個帶有未知名狀態(tài)碼的響應(yīng)消息。
第一個數(shù)字代表狀態(tài)碼的分類，其他兩個數(shù)字沒有明顯的分類規(guī)則，總共有5類狀態(tài)碼：
1XX (Informational信息)： 請求被接收，持續(xù)處理的過程。
2XX (Successfull成功): 請求被成功接收，解讀和接受。
3XX (Redirection重定向): 為了完成請求過程，更多的動作需要去執(zhí)行。
4XX (Client error 客戶端錯誤): 請求包含錯誤的語法或者不能被實現(xiàn)。
5XX (Server error 服務(wù)器錯誤): 服務(wù)器不能實現(xiàn)一個顯然合法的請求。
reason-phrase = *( HTAB / SP / VCHAR / obs-text )
reason-phrase設(shè)計的最底層目的是為了提供一個當(dāng)前狀態(tài)碼的文本描述?？蛻舳丝珊雎?。
1.4、Header Fields 頭部字段
每一個頭部字段由一個大小寫不敏感的字段名字，跟著一個冒號，可選的空格，字段值和可選的尾部空格組成。
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
一個HTTP消息的消息正文是用來攜帶請求或者響應(yīng)的負載正文。
消息體是和有效載荷體是一致的，除非一個傳輸編碼已經(jīng)被完成。
消息中允許的消息主體的規(guī)則在請求和響應(yīng)中是不同的。
request 請求中的 message body的預(yù)定義是被 Content-Length 或 Transfer-Encoding 頭部字段控制。
請求消息框架是和method的語義無關(guān)的。甚至請求方法對消息體沒有任何用處。
響應(yīng)消息中的message body存在與否決定于請求的方法和響應(yīng)返回的狀態(tài)碼。
HEAD請求不會返回 message body，因為它只是關(guān)聯(lián)響應(yīng)頭部字段。即使存在 message body ，如果方法是GET也是表明將會顯示什么值.
所有 1XX 204 304 都不會有 message body.
2、Standard request fields 標(biāo)準(zhǔn)請求頭字段
| 字段名 | 說明 | 舉例 |
|---|---|---|
| A-IM | 對請求可接受的接口實例化,同accept | A-IM: feed |
| Accept | response可接受的媒體類型 | Accept: text/html<br />其他：text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 |
| Accept-Charset | 可接受的字符集 | Accept-Charset: utf-8 |
| Accept-Encoding | 可接受的文件解碼格式 | Accept-Encoding: gzip, deflate |
| Accept-Language | response可接受的人類語言 | Accept-Language: en-US |
| Accept-Datetime | 可接受的時間版本 | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT |
| Access-Control-Request-Method, Access-Control-Request-Headers |
利用origin發(fā)起跨域資源請求 | Access-Control-Request-Method: GET<br /> |
| Authorization | HTTP認證 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 用來指定一個在請求響應(yīng)鏈中所有緩存機制必須遵守的一個指令 | Cache-Control: no-cache |
| Connection | 當(dāng)前連接和持續(xù)請求的的控制參數(shù)。HTTP/2不得用這個方法，默認持續(xù)連接 | Connection: keep-alive<br />Connection: Upgrade |
| Content-Length | request body的長度 | Content-Length: 348 |
| Content-Type | request body的媒體格式（POST 和 PUT適用） | Content-Type: application/x-www-form-urlencoded |
| Cookie | 一個被服務(wù)器用set-cookie發(fā)送的數(shù)據(jù) | Cookie: $Version=1; Skin=new; |
| Date | message發(fā)出的時間 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Expect | 客戶端表明的特殊的服務(wù)器要做的行為 | Expect: 100-continue |
