7.6.2.3 訊息長度的總結
rfc 2616
對訊息的長度總結如下：乙個訊息的transfer-length（傳輸長度）是指訊息中的message-body（訊息體）的長度。當應用了transfer-coding（傳輸編碼），每個訊息中的message-body（訊息體）的長度（transfer-length）由以下幾種情況決定（優先順序由高到低）：
(1)任何不含有訊息體的訊息（如1***、204、304等響應訊息和任何頭(head，首部)請求的響應訊息），總是由乙個空行（clrf）結束。
(2)如果出現了transfer-encoding頭欄位 並且值為非「identity」，那麼transfer-length由「chunked」 傳輸編碼定義，除非訊息由於關閉連線而終止。
(3)如果出現了content-length頭欄位，它的值表示entity-length（實體長度）和transfer-length（傳輸長度）。如果這兩個長度的大小不一樣（i.e.設定了transfer-encoding頭欄位），那麼將不能傳送content-length頭欄位。並且如果同時收到了transfer-encoding欄位和content-length頭欄位，那麼必須忽略content-length欄位。
(4)如果訊息使用**型別「multipart/byteranges」，並且transfer-length 沒有另外指定，那麼這種自定界（self-delimiting）**型別定義transfer-length 。除非傳送者知道接收者能夠解析該型別，否則不能使用該型別。
(5)由伺服器關閉連線確定訊息長度。（注意：關閉連線不能用於確定請求訊息的結束，因為伺服器不能再發響應訊息給客戶端了。）
為了相容http/1.0應用程式，http/1.1的請求訊息體中必須包含乙個合法的content-length頭欄位，除非知道伺服器相容http/1.1。乙個請求包含訊息體，並且content-length欄位沒有給定，如果不能判斷訊息的長度，伺服器應該用用400 (bad request) 來響應；或者伺服器堅持希望收到乙個合法的content-length欄位，用 411 (length required)來響應。
所有http/1.1的接收者應用程式必須接受「chunked」 transfer-coding (傳輸編碼)，因此當不能事先知道訊息的長度，允許使用這種機制來傳輸訊息。訊息不應該夠同時包含 content-length頭字段和non-identity transfer-coding。如果乙個訊息同時包含non-identity transfer-coding和content-length，必須忽略content-length 。
APP開發實戰61 Activity訊息路由
在android開發中，常遇到多個activity間的相互通訊和呼叫，這樣會導致acticity間的橫向依賴。android中，開啟頁面的方式主要是startactivity 使用startactivity 的缺點是需要開啟的那個activity的類已經存在，否則無法通過編譯，但是在協同開發中，這往...
APP開發實戰24 HTTP協議簡介
http 超文字傳輸協議 hypertexttransfer protocol 是網際網路 上應用最為廣泛的一種網路協議 是全球資訊網協會 world wide web consortium 和internet工作小組 internet engineeringtask force 合作的結果，二者發...
APP開發實戰19 TCP和HTTP連線
手機能夠使用聯網功能是因為手機底層實現了 tcp ip 協議，可以使手機終端通過無線網路建立 tcp連線。tcp協議可以對上層網路提供介面，使上層網路資料的傳輸建立在 無差別 的網路之上。建立起乙個 tcp連線需要經過 三次握手 第一次握手 客戶端傳送 syn包 syn j 到伺服器，並進入 syn...