HTTP響應頭有效，沒有傳輸編碼和內容長度？

Question

即使不包含Content-Length或Transfer-Encoding，HTTP響應頭（如下所示）是否合法？

- Http: Response, HTTP/1.1, Status: Ok, URL: /AAA/B.json 
    ProtocolVersion: HTTP/1.1 
    StatusCode: 200, Ok 
    Reason: OK 
    Expires: Fri, 05 Oct 2012 01:41:30 GMT 
    Date: Fri, 05 Oct 2012 01:40:46 GMT 
    Vary: Accept-Encoding 
    Accept-Ranges: bytes 
    Cache-Control: public, max-age=43 
    Server: Noelios-Restlet-Engine/1.1.10 
    ContentType: application/json;charset=UTF-8 
    ContentEncoding: gzip 
    Connection: close 
    X-Served-By: 85.111 
    HeaderEnd: CRLF 

我期望看到Content-Length或Transfer-Encoding，但它們都不存在。

我讀了HTTP-RFC，但我仍然不確定。

@CodeCaster，我看過RFC 4.4節，但我仍不清楚，你可以看到，響應報頭是用來返回一個JSON數據流，所以：

• 4.4節，第1所定義不得包含消息體，似乎不適用於我的情況。
• 4.4節，規則4，對此不太確定，但由於在響應頭中沒有看到「multipart/byteranges」 - 是否意味着這條規則不適用於我？
• 第4.4節規則5，由於標題實際包含「連接：關閉」，這對我來說大多不清楚，它是相關的嗎？

那麼，還有什麼意見？

Answer 1

是的，它是有效的。有五種方法，以確定消息長度：

RFC 2616 Section 4.4. Message Length：

消息的轉發長度是所述消息體的長度爲 它出現在消息中;也就是說，在任何傳輸編碼已經應用 之後。當消息體是包含在消息中，該機構的 轉發長度由下列 之一（按照優先級的順序）來確定：

1. 任何響應消息「不能」包括消息體（例如 作爲1xx，204和304響應以及對HEAD 請求的任何響應）始終由 標頭字段後面的第一個空行終止，而不管 中存在的實體標頭字段信息。

2. 如果Transfer-Encoding頭字段（部分14.41）存在和 具有由使用的「分塊」傳輸編碼（見第3.6節中定義比「同一性」之外的任何值，則轉發長度是 ）， ，除非消息通過關閉連接而終止。

3. 如果存在內容長度標頭字段（14.13節），則其OCTET中的其十進制值即 表示實體長度和傳輸長度。如果這兩個長度不同（即，如果存在傳輸編碼 標題字段），則不應發送內容長度標題字段 。如果一個消息同時收到一個 Transfer-Encoding頭域和一個Content-Length頭域， ，後者務必被忽略。

4. 如果該消息使用的媒體類型「多部分/字節範圍」，並且不另外指明，否則 轉發長度，則該自 界定媒體類型定義了傳輸長度。除非發件人知道收件人可以解析它 ;在來自1.1客戶端的具有多個字節範圍說明符的Range頭部的請求中存在意味着客戶端可以解析 多部分/字節範圍響應。

   範圍標題可能會被1.0代理轉發，而不是 可以理解multipart/byteranges;在這種情況下，服務器必須使用本節中 的第1,3或5項中定義的方法對消息進行分隔。

5. 由服務器關閉連接。 （關閉連接 不能用於指示請求主體的結束，因爲這 會留下任何可能性服務器發回一個響應。）