HTTP1.1翻譯<4>

          Posted on 2005-09-21 21:21 英雄 閱讀(1513) 評論(0)  編輯  收藏 所屬分類: HTTP1.1協(xié)議中文翻譯

          4.HTTP 消息

          41消息類型

          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/10client實現(xiàn)產(chǎn)生額外的CRLF在一個POSTrequest后。重申一下在 BNF處的禁令,一個HTTP/11client絕對不能在一個request的前后加CRLF

          42消息頭

          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)然需要使用最少一個SPHT來作為多出行的引導(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ū),然后是requestresponse頭區(qū),以entity-header頭區(qū)結(jié)束。

          在一個消息中可以出現(xiàn)多頭區(qū)對應(yīng)同一個區(qū)名,只要對那個頭區(qū)的頭區(qū)值是可以用逗號分隔的列表。必須可能把多個頭區(qū)合并成“name:value”對而不改變語義。順序是重要的,因為解釋需要順序,而且因此一個proxy絕對不能改變順序。

          43消息體

          HTTP消息的消息體被用來攜帶跟隨requestresponse的實體。消息體只在一個傳輸編碼被使用時才和實體不同。

          message-body = entity-body

          | <entity-body encoded as per Transfer-Encoding>

          當(dāng)要保證消息被安全和合適傳輸時需要傳輸編碼,Transfer-Encoding就是用來指示傳輸編碼的。這是消息的一個屬性,而不是實體的,因此可以在request/response鏈中被增加或刪除。(但是,sec3.6增加了什么時候可以用這個屬性)。

          什么情況下確定消息中有一個消息體在requestresponse不同的。

          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,204304也肯定沒有。所有其它的一定有,即使它可能是0長度。

          44消息長度

          消息長度是指在傳輸編碼使用后消息體的長度。當(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/byterangesproxy傳遞,在這種情況下,server必須使用135提供的方法定界。

          5.到server關(guān)閉一個連接(關(guān)閉連接不能被用來指示一個request的結(jié)束,因為那樣將導(dǎo)致server無法發(fā)送一個response。)

          為了和HTTP/10應(yīng)用兼容,包含一個消息體的。1請求肯定包含一個有效的Content-Length

          除非知道serverHTTP/11兼容。如果一個request包含一個消息體而沒有

          Content-Length,那么server如果不能決定消息的長度應(yīng)該回以400,或411如果它堅持接收一個有效Content-Length

          所有接收實體的HTTP/11應(yīng)用必須接收“chunked”傳輸編碼(sec3.6),因此允許使用這個機制決定消息長度。

          消息絕對不能同時包含Content-Length頭區(qū)和一個非identity傳輸編碼。如果一定包含,那么Content-Length被忽略。

          如果一個Content-Length真被給出了,那 它一定對應(yīng)消息體的字節(jié)個數(shù)。HTTP/11user agent必須告訴用戶如果一個無效長度被接受和看到。

          45通用頭區(qū)

          有一些頭區(qū)在requestresponse中通用,但是不能用于被傳輸?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ū)。

           

          主站蜘蛛池模板: 福泉市| 班戈县| 乌兰县| 乡宁县| 牙克石市| 雅江县| 垦利县| 武冈市| 邵阳市| 信阳市| 泌阳县| 永川市| 永城市| 通化县| 福安市| 黑山县| 沁源县| 个旧市| 深圳市| 郸城县| 卢龙县| 奎屯市| 芦溪县| 柞水县| 屏南县| 嘉峪关市| 建始县| 汽车| 巢湖市| 普安县| 陇西县| 淳安县| 中牟县| 慈利县| 安乡县| 宜章县| 陆河县| 大英县| 色达县| 卢氏县| 瑞昌市|