4.HTTP 消息
4.1消息類型
HTTP消息由客戶端發(fā)到服務(wù)器端的request和相反方向的response組成。
HTTP-message = Request | Response ; HTTP/1.1 messages
Request(sec5)和response(sec6)消息使用RFC822[9]的通用消息格式來傳遞實體(message的有效負(fù)荷)。由一個開始行,0或多個頭區(qū)(頭部),一個空行(在CRLF前什么也沒有)來指示頭區(qū)結(jié)束,和一個可能的body。
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
為了保持健壯性,服務(wù)器應(yīng)該在Request-Line被期待的地方忽略任何空行。換句話說,如果服務(wù)器在消息的開始讀協(xié)議流,首先接收了一個CRLF,它應(yīng)該忽略crlf。
某些臭蟲很多的HTTP/1。0client實現(xiàn)產(chǎn)生額外的CRLF在一個POSTrequest后。重申一下在 BNF處的禁令,一個HTTP/1。1client絕對不能在一個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])。每一個頭區(qū)由一個名字跟著一個:和一個區(qū)值組成。區(qū)名是大小寫不敏感的。區(qū)值可以一任何數(shù)目的LWS開頭,雖然一個SP最好。頭區(qū)可以擴展成多行,當(dāng)然需要使用最少一個SP或HT來作為多出行的引導(dǎo)。應(yīng)用應(yīng)該遵從都知道的或被指明的通用形式來產(chǎn)生HTTP結(jié)構(gòu),因為可能出現(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é)束。
在一個消息中可以出現(xiàn)多頭區(qū)對應(yīng)同一個區(qū)名,只要對那個頭區(qū)的頭區(qū)值是可以用逗號分隔的列表。必須可能把多個頭區(qū)合并成“name:value”對而不改變語義。順序是重要的,因為解釋需要順序,而且因此一個proxy絕對不能改變順序。
4.3消息體
HTTP消息的消息體被用來攜帶跟隨request和response的實體。消息體只在一個傳輸編碼被使用時才和實體不同。
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
當(dāng)要保證消息被安全和合適傳輸時需要傳輸編碼,Transfer-Encoding就是用來指示傳輸編碼的。這是消息的一個屬性,而不是實體的,因此可以在request/response鏈中被增加或刪除。(但是,sec3.6增加了什么時候可以用這個屬性)。
什么情況下確定消息中有一個消息體在request和response不同的。
Request是當(dāng)包含Content-Length 或 Transfer-Encoding頭區(qū)時有消息體。如果一個 request的方法定義中不允許一個消息體包含在消息中發(fā)送,那么就絕對不能。一個server應(yīng)該讀或傳遞一個消息中的消息體,而如果request中的方法定義中沒有指示消息體,那就應(yīng)該忽略過去。
對于response,有無則依賴于request的方法和response的狀態(tài)碼(sec6.1.1)。所有對應(yīng)HEADrequest 方法的肯定沒有,即使實體頭區(qū)的存在可能讓人相信它存在。所有的1xx,204和304也肯定沒有。所有其它的一定有,即使它可能是0長度。
4.4消息長度
消息長度是指在傳輸編碼使用后消息體的長度。當(dāng)一個消息體被包含在一個消息中時,體長由下面決定(按優(yōu)先級的順序):
1. 任何肯定不包含一個消息體的response消息總是在第一個空行處終結(jié),而無論出現(xiàn)在消息中的實體的頭區(qū)。
2. 如果一個Transfer-Encoding頭區(qū)(sec14.41)被給出而且只有”identity”,那么傳輸長度是使用“chunked”傳輸編碼,直到連接被關(guān)閉消息被終結(jié)。
3. 如果一個Content-Length頭區(qū)(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關(guān)閉一個連接(關(guān)閉連接不能被用來指示一個request的結(jié)束,因為那樣將導(dǎo)致server無法發(fā)送一個response。)
為了和HTTP/1。0應(yīng)用兼容,包含一個消息體的。1請求肯定包含一個有效的Content-Length
除非知道server是HTTP/1。1兼容。如果一個request包含一個消息體而沒有
Content-Length,那么server如果不能決定消息的長度應(yīng)該回以400,或411如果它堅持接收一個有效Content-Length。
所有接收實體的HTTP/1。1應(yīng)用必須接收“chunked”傳輸編碼(sec3.6),因此允許使用這個機制決定消息長度。
消息絕對不能同時包含Content-Length頭區(qū)和一個非identity傳輸編碼。如果一定包含,那么Content-Length被忽略。
如果一個Content-Length真被給出了,那 它一定對應(yīng)消息體的字節(jié)個數(shù)。HTTP/1。1user agent必須告訴用戶如果一個無效長度被接受和看到。
4.5通用頭區(qū)
有一些頭區(qū)在request和response中通用,但是不能用于被傳輸?shù)膶嶓w。這些頭區(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ū)的名字可以跟隨一個改變的版本號而被擴展。但是,新的或?qū)嶒灥念^區(qū)可以被給通用頭區(qū)的語義如果通訊雙方都認(rèn)同。認(rèn)不出的頭區(qū)被認(rèn)為是實體頭區(qū)。