4.HTTP 消息
4．1消息類型
HTTP消息由客戶端發(fā)到服務(wù)器端的request和相反方向的response組成。
HTTP-message = Request | Response ; HTTP/1.1 messages
Request(sec5)和response(sec6)消息使用RFC822[9]的通用消息格式來傳遞實(shí)體（message的有效負(fù)荷）。由一個(gè)開始行，0或多個(gè)頭區(qū)（頭部），一個(gè)空行（在CRLF前什么也沒有）來指示頭區(qū)結(jié)束，和一個(gè)可能的body。
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
為了保持健壯性，服務(wù)器應(yīng)該在Request-Line被期待的地方忽略任何空行。換句話說，如果服務(wù)器在消息的開始讀協(xié)議流，首先接收了一個(gè)CRLF，它應(yīng)該忽略crlf。
某些臭蟲很多的HTTP/1。0client實(shí)現(xiàn)產(chǎn)生額外的CRLF在一個(gè)POSTrequest后。重申一下在 BNF處的禁令，一個(gè)HTTP/1。1client絕對(duì)不能在一個(gè)request的前后加CRLF。
4．2消息頭
HTTP頭區(qū)，包含general-header (section 4.5), request-header (section 5.3), response-header
(section 6.2), 和 entity-header (section 7.1) fields，遵從通用的格式定義（sec3.1RFC822[9]）。每一個(gè)頭區(qū)由一個(gè)名字跟著一個(gè)：和一個(gè)區(qū)值組成。區(qū)名是大小寫不敏感的。區(qū)值可以一任何數(shù)目的LWS開頭，雖然一個(gè)SP最好。頭區(qū)可以擴(kuò)展成多行，當(dāng)然需要使用最少一個(gè)SP或HT來作為多出行的引導(dǎo)。應(yīng)用應(yīng)該遵從都知道的或被指明的通用形式來產(chǎn)生HTTP結(jié)構(gòu)，因?yàn)榭赡艹霈F(xiàn)某些應(yīng)用無法接受超出通用形式的東西。
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
field-content并沒有包含任何打頭的或結(jié)尾的LWS：出現(xiàn)在非空格字符前或后。而這樣出現(xiàn)的LWS可以在不改變區(qū)值語義的情況下被刪除掉。任何出現(xiàn)在field-content之間的LWS可以在解釋區(qū)值或轉(zhuǎn)向消息流前以SP取代之。
不同區(qū)名的頭區(qū)出現(xiàn)順序不相同也沒有關(guān)系。但是，最好首先發(fā)送通用頭區(qū)，然后是request或response頭區(qū)，以entity-header頭區(qū)結(jié)束。
在一個(gè)消息中可以出現(xiàn)多頭區(qū)對(duì)應(yīng)同一個(gè)區(qū)名，只要對(duì)那個(gè)頭區(qū)的頭區(qū)值是可以用逗號(hào)分隔的列表。必須可能把多個(gè)頭區(qū)合并成“name:value”對(duì)而不改變語義。順序是重要的，因?yàn)榻忉屝枰樞颍乙虼艘粋€(gè)proxy絕對(duì)不能改變順序。
4．3消息體
HTTP消息的消息體被用來攜帶跟隨request和response的實(shí)體。消息體只在一個(gè)傳輸編碼被使用時(shí)才和實(shí)體不同。
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
當(dāng)要保證消息被安全和合適傳輸時(shí)需要傳輸編碼，Transfer-Encoding就是用來指示傳輸編碼的。這是消息的一個(gè)屬性，而不是實(shí)體的，因此可以在request/response鏈中被增加或刪除。（但是，sec3.6增加了什么時(shí)候可以用這個(gè)屬性）。
什么情況下確定消息中有一個(gè)消息體在request和response不同的。
Request是當(dāng)包含Content-Length 或 Transfer-Encoding頭區(qū)時(shí)有消息體。如果一個(gè) request的方法定義中不允許一個(gè)消息體包含在消息中發(fā)送，那么就絕對(duì)不能。一個(gè)server應(yīng)該讀或傳遞一個(gè)消息中的消息體，而如果request中的方法定義中沒有指示消息體，那就應(yīng)該忽略過去。
對(duì)于response，有無則依賴于request的方法和response的狀態(tài)碼（sec6.1.1）。所有對(duì)應(yīng)HEADrequest 方法的肯定沒有，即使實(shí)體頭區(qū)的存在可能讓人相信它存在。所有的1xx,204和304也肯定沒有。所有其它的一定有，即使它可能是0長(zhǎng)度。
4．4消息長(zhǎng)度
消息長(zhǎng)度是指在傳輸編碼使用后消息體的長(zhǎng)度。當(dāng)一個(gè)消息體被包含在一個(gè)消息中時(shí)，體長(zhǎng)由下面決定（按優(yōu)先級(jí)的順序）：
1． 任何肯定不包含一個(gè)消息體的response消息總是在第一個(gè)空行處終結(jié)，而無論出現(xiàn)在消息中的實(shí)體的頭區(qū)。
2． 如果一個(gè)Transfer-Encoding頭區(qū)（sec14.41）被給出而且只有”identity”，那么傳輸長(zhǎng)度是使用“chunked”傳輸編碼，直到連接被關(guān)閉消息被終結(jié)。
3． 如果一個(gè)Content-Length頭區(qū)（sec14.13）被給出，那么它既代表了實(shí)體長(zhǎng)度也代表了傳輸長(zhǎng)度。如果這兩個(gè)長(zhǎng)度不相等肯定不會(huì)有Content-Length。如果一個(gè)消息既存在Transfer-Encoding又存在Content-Length，后者被忽略。
4．如果消息使用“multipart/byteranges”做媒體類型，并且transfer-length也沒被給出，那么這個(gè)自定界的媒體類型定義了傳輸長(zhǎng)度。這個(gè)類型如果接收者無法解析它那肯定不能被使用；在一個(gè)request中，如果包含一個(gè)Range頭和若干byte-range說明那個(gè)client能夠解析multipart/ranges。一個(gè)rang頭可能被一個(gè)不理解multipart/byteranges的proxy傳遞，在這種情況下，server必須使用1，3，5提供的方法定界。
5．到server關(guān)閉一個(gè)連接（關(guān)閉連接不能被用來指示一個(gè)request的結(jié)束，因?yàn)槟菢訉?dǎo)致server無法發(fā)送一個(gè)response。）
為了和HTTP/1。0應(yīng)用兼容，包含一個(gè)消息體的。1請(qǐng)求肯定包含一個(gè)有效的Content-Length
除非知道server是HTTP/1。1兼容。如果一個(gè)request包含一個(gè)消息體而沒有
Content-Length，那么server如果不能決定消息的長(zhǎng)度應(yīng)該回以400，或411如果它堅(jiān)持接收一個(gè)有效Content-Length。
所有接收實(shí)體的HTTP/1。1應(yīng)用必須接收“chunked”傳輸編碼（sec3.6），因此允許使用這個(gè)機(jī)制決定消息長(zhǎng)度。
消息絕對(duì)不能同時(shí)包含Content-Length頭區(qū)和一個(gè)非identity傳輸編碼。如果一定包含，那么Content-Length被忽略。
如果一個(gè)Content-Length真被給出了，那 它一定對(duì)應(yīng)消息體的字節(jié)個(gè)數(shù)。HTTP/1。1user agent必須告訴用戶如果一個(gè)無效長(zhǎng)度被接受和看到。
4．5通用頭區(qū)
有一些頭區(qū)在request和response中通用，但是不能用于被傳輸?shù)膶?shí)體。這些頭區(qū)只用于被傳遞的消息。
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
通用頭區(qū)的名字可以跟隨一個(gè)改變的版本號(hào)而被擴(kuò)展。但是，新的或?qū)嶒?yàn)的頭區(qū)可以被給通用頭區(qū)的語義如果通訊雙方都認(rèn)同。認(rèn)不出的頭區(qū)被認(rèn)為是實(shí)體頭區(qū)。