4.HTTP 消息
4．1消息類型
HTTP消息由客戶端發到服務器端的request和相反方向的response組成。
HTTP-message = Request | Response ; HTTP/1.1 messages
Request(sec5)和response(sec6)消息使用RFC822[9]的通用消息格式來傳遞實體（message的有效負荷）。由一個開始行，0或多個頭區（頭部），一個空行（在CRLF前什么也沒有）來指示頭區結束，和一個可能的body。
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
為了保持健壯性，服務器應該在Request-Line被期待的地方忽略任何空行。換句話說，如果服務器在消息的開始讀協議流，首先接收了一個CRLF，它應該忽略crlf。
某些臭蟲很多的HTTP/1。0client實現產生額外的CRLF在一個POSTrequest后。重申一下在 BNF處的禁令，一個HTTP/1。1client絕對不能在一個request的前后加CRLF。
4．2消息頭
HTTP頭區，包含general-header (section 4.5), request-header (section 5.3), response-header
(section 6.2), 和 entity-header (section 7.1) fields，遵從通用的格式定義（sec3.1RFC822[9]）。每一個頭區由一個名字跟著一個：和一個區值組成。區名是大小寫不敏感的。區值可以一任何數目的LWS開頭，雖然一個SP最好。頭區可以擴展成多行，當然需要使用最少一個SP或HT來作為多出行的引導。應用應該遵從都知道的或被指明的通用形式來產生HTTP結構，因為可能出現某些應用無法接受超出通用形式的東西。
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并沒有包含任何打頭的或結尾的LWS：出現在非空格字符前或后。而這樣出現的LWS可以在不改變區值語義的情況下被刪除掉。任何出現在field-content之間的LWS可以在解釋區值或轉向消息流前以SP取代之。
不同區名的頭區出現順序不相同也沒有關系。但是，最好首先發送通用頭區，然后是request或response頭區，以entity-header頭區結束。
在一個消息中可以出現多頭區對應同一個區名，只要對那個頭區的頭區值是可以用逗號分隔的列表。必須可能把多個頭區合并成“name:value”對而不改變語義。順序是重要的，因為解釋需要順序，而且因此一個proxy絕對不能改變順序。
4．3消息體
HTTP消息的消息體被用來攜帶跟隨request和response的實體。消息體只在一個傳輸編碼被使用時才和實體不同。
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
當要保證消息被安全和合適傳輸時需要傳輸編碼，Transfer-Encoding就是用來指示傳輸編碼的。這是消息的一個屬性，而不是實體的，因此可以在request/response鏈中被增加或刪除。（但是，sec3.6增加了什么時候可以用這個屬性）。
什么情況下確定消息中有一個消息體在request和response不同的。
Request是當包含Content-Length 或 Transfer-Encoding頭區時有消息體。如果一個 request的方法定義中不允許一個消息體包含在消息中發送，那么就絕對不能。一個server應該讀或傳遞一個消息中的消息體，而如果request中的方法定義中沒有指示消息體，那就應該忽略過去。
對于response，有無則依賴于request的方法和response的狀態碼（sec6.1.1）。所有對應HEADrequest 方法的肯定沒有，即使實體頭區的存在可能讓人相信它存在。所有的1xx,204和304也肯定沒有。所有其它的一定有，即使它可能是0長度。
4．4消息長度
消息長度是指在傳輸編碼使用后消息體的長度。當一個消息體被包含在一個消息中時，體長由下面決定（按優先級的順序）：
1． 任何肯定不包含一個消息體的response消息總是在第一個空行處終結，而無論出現在消息中的實體的頭區。
2． 如果一個Transfer-Encoding頭區（sec14.41）被給出而且只有”identity”，那么傳輸長度是使用“chunked”傳輸編碼，直到連接被關閉消息被終結。
3． 如果一個Content-Length頭區（sec14.13）被給出，那么它既代表了實體長度也代表了傳輸長度。如果這兩個長度不相等肯定不會有Content-Length。如果一個消息既存在Transfer-Encoding又存在Content-Length，后者被忽略。
4．如果消息使用“multipart/byteranges”做媒體類型，并且transfer-length也沒被給出，那么這個自定界的媒體類型定義了傳輸長度。這個類型如果接收者無法解析它那肯定不能被使用；在一個request中，如果包含一個Range頭和若干byte-range說明那個client能夠解析multipart/ranges。一個rang頭可能被一個不理解multipart/byteranges的proxy傳遞，在這種情況下，server必須使用1，3，5提供的方法定界。
5．到server關閉一個連接（關閉連接不能被用來指示一個request的結束，因為那樣將導致server無法發送一個response。）
為了和HTTP/1。0應用兼容，包含一個消息體的。1請求肯定包含一個有效的Content-Length
除非知道server是HTTP/1。1兼容。如果一個request包含一個消息體而沒有
Content-Length，那么server如果不能決定消息的長度應該回以400，或411如果它堅持接收一個有效Content-Length。
所有接收實體的HTTP/1。1應用必須接收“chunked”傳輸編碼（sec3.6），因此允許使用這個機制決定消息長度。
消息絕對不能同時包含Content-Length頭區和一個非identity傳輸編碼。如果一定包含，那么Content-Length被忽略。
如果一個Content-Length真被給出了，那 它一定對應消息體的字節個數。HTTP/1。1user agent必須告訴用戶如果一個無效長度被接受和看到。
4．5通用頭區
有一些頭區在request和response中通用，但是不能用于被傳輸的實體。這些頭區只用于被傳遞的消息。
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
通用頭區的名字可以跟隨一個改變的版本號而被擴展。但是，新的或實驗的頭區可以被給通用頭區的語義如果通訊雙方都認同。認不出的頭區被認為是實體頭區。