最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案的標籤之前，導致返回的xml檔案無法得到正確解析.
問題現象
使用fire bug檢測響應頭和body截圖如下：
問題原因
原來http協議規定客戶端有兩種方式接收響應，http響應一次返回資料，客戶端根據響應頭的content-length值確定響應長度，即客戶端應接收的內容長度；另一種情況是乙個http請求分多次返回響應內容，每個返回包返回一定長度的「內容塊」，直到最後接到乙個長度為「0「的包結束響應。
通常，http協議中使用content-length這個頭來告知報文的長度。然後，在資料下行的過程中，content-length的方式要預先在伺服器中快取所有資料，然後所有資料再一股腦兒地發給客戶端。
如果要一邊產生資料，一邊發給客戶端，web 伺服器就需要使用」transfer-encoding: chunked」這樣的方式來代替content-length。
由於第3方系統強制要求，服務端必須返回content-length頭，所以在解析的時候，由於採用transfer-encoding:chunked方式返回，content-length=0，由於第3方系統無法正確確定報文的長度，導致多餘字串的生產。
chunked編碼
般http通訊時，會使用content-length頭資訊性來通知使用者**（通常意義上是瀏覽器）伺服器傳送的文件內容長度，該頭資訊定義於http1.0協議rfc 1945 10.4章節中。瀏覽器接收到此頭資訊後，接受完content-length中定義的長度位元組後開始解析頁面，但如果服務端有部分資料延遲傳送嗎，則會出現瀏覽器白屏，造成比較糟糕的使用者體驗。
HTTP響應Chunked編碼
最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案...
HTTP協議chunked編碼
當不能預先確定報文體的長度時，不可能在頭中包含content length域來指明報文體長度，此時就需要通過transfer encoding域來確定報文體長度。此時，transfer encoding域的值應當為chunked，表明採用chunked編碼方式來進行報文體的傳輸。chunked編碼是...
http協議裡的chunked編碼與測試
分塊傳輸編碼 chunked transfer encoding 是只在http協議1.1版本 http 1.1 中提供的一種資料傳送機制。以往http的應答中資料是整個一起傳送的，並在應答頭里content length欄位標識了資料的長度，以便客戶端知道應答訊息的結束。對於動態生成的應答內容來說...