當不能預先確定報文體的長度時，不可能在頭中包含content-length域來指明報文體長度，此時就需要通過transfer-encoding域來確定報文體長度。 此時，transfer-encoding域的值應當為chunked，表明採用chunked編碼方式來進行報文體的傳輸。chunked編碼是http/1.1 rfc裡定義的一種編碼方式，因此所有的http/1.1應用都應當支援此方式。
chunked編碼的基本方法是將大塊資料分解成多塊小資料，每塊都可以自指定長度，其具體格式如下（bnf文法：
chunked-body = *chunk //0至多個chunk
last-chunk //最後乙個chunk
trailer //尾部
crlf //結束標記符
chunk = chunk-size [ chunk-extension ] crlf
chunk-data crlf
chunk-size = 1*hex
last-chunk = 1*("0") [ chunk-extension ] crlf
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(octet)
trailer = *(entity-header crlf)
解釋：chunked-body表示經過chunked編碼後的報文體。報文體可以分為chunk, last-chunk，trailer和結束符四部分。chunk的數量在報文體中最少可以為0，無上限；每個chunk的長度是自指定的，即，起始的資料必然是16進製制數字的字串，代表後面chunk-data的長度（位元組數）。這個16進製制的字串第乙個字元如果是「0」，則表示chunk- size為0，該chunk為last-chunk,無chunk-data部分。可選的chunk-extension由通訊雙方自行確定，如果接收者不理解它的意義，可以忽略。
trailer是附加的在尾部的額外頭域，通常包含一些元資料（metadata, meta means "about information"），這些頭域可以在解碼後附加在現有頭域之後。
HTTP響應Chunked編碼
最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案...
HTTP響應Chunked編碼
最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案...
http協議裡的chunked編碼與測試
分塊傳輸編碼 chunked transfer encoding 是只在http協議1.1版本 http 1.1 中提供的一種資料傳送機制。以往http的應答中資料是整個一起傳送的，並在應答頭里content length欄位標識了資料的長度，以便客戶端知道應答訊息的結束。對於動態生成的應答內容來說...