最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送一個XML報文，我方根據請求報文響應資料，並以XML格式進行返回.測試的時候發現一個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是XML格式的，這些多餘字串在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中定義的長度位元組後開始解析頁面，但如果服務端有部分資料延遲傳送嗎，則會出現瀏覽器白屏，造成比較糟糕的使用者體驗。

解決方案是在HTTP1.1協議中，RFC 2616中14.41章節中定義的Transfer-Encoding: chunked的頭資訊，chunked編碼定義在3.6.1中，所有HTTP1.1 應用都支援此使用trunked編碼動態的提供body內容的長度的方式。進行Chunked編碼傳輸的HTTP資料要在訊息頭部設定：Transfer-Encoding: chunked表示Content Body將用chunked編碼傳輸內容。根據定義，瀏覽器不需要等到內容位元組全部下載完成,只要接收到一個chunked塊就可解析頁面.並且可以下載html中定義的頁面內容,包括js,css,image等。