報文中的HTTP_CONTENT_LENGTH通常是十進制數(shù)字，單位是字節(jié)(b)

Content-Length

Content-Length是HTTP消息長度, 用十進制數(shù)字表示的八位字節(jié)的數(shù)目, 是Headers中常見的一個字段. Content-Length應(yīng)該是精確的, 否則就會導(dǎo)致異常 (特別地, HTTP1.0中這個字段可有可無).

Content-Length首部指示出報文中實體主體的字節(jié)大小. 這個大小是包含了所有內(nèi)容編碼的, 比如, 對文本文件進行了gzip壓縮的話, Content-Length首部指的就是壓縮后的大小而不是原始大小

Content-length 長度與實際長度不一致

Content-Length, HTTP消息長度, 用十進制數(shù)字表示的八位字節(jié)的數(shù)目. 一般情況下, 很多工作都被框架完成, 我們很少去關(guān)注這部分內(nèi)容, 但少數(shù)情況下發(fā)生了Content-Length與實際消息長度不一致, 程序可能會發(fā)生比較奇怪的異常, 如:

• 請求時長度不一致

• 無響應(yīng)直到超時.

• 響應(yīng)時長度不一致

• 請求被截斷, 而且下一個請求解析出現(xiàn)錯亂

Content-Length 工作原理

Content-Length使用十進制的數(shù)字表示了消息的長度, 服務(wù)端/客戶端通過它來得知后續(xù)要讀取消息的長度

Transfer-Encoding

當(dāng)請求處理完成前無法獲取消息長度, 我們就無法明確指定Content-Length, 此時應(yīng)該使用Transfer-Encoding: chunked

什么是Transfer-Encoding: chunked

數(shù)據(jù)以一系列分塊的形式進行發(fā)送. Content-Length 首部在這種情況下不被發(fā)送. 在每一個分塊的開頭需要添加當(dāng)前分塊的長度, 以十六進制的形式表示，后面緊跟著 \r\n , 之后是分塊本身, 后面也是\r\n. 終止塊是一個常規(guī)的分塊, 不同之處在于其長度為0

Transfer-Encodeing 工作原理

在wireshark中可以很清晰地看到chunked的數(shù)據(jù), 其結(jié)構(gòu)大致是: 返回的消息被分為多個數(shù)據(jù)塊, 每個數(shù)據(jù)塊有兩部分, 長度 + 數(shù)據(jù), 這兩部分都以CRLF(即\r\n)結(jié)尾. 而終止塊是一個特殊的數(shù)據(jù)塊, 其長度為0

結(jié)論

• Content-Length如果存在且生效, 必須是正確的, 否則會發(fā)生異常.(大于實際值會超時, 小于實際值會截斷并可能導(dǎo)致后續(xù)的數(shù)據(jù)解析混亂)

• 如果報文中包含Transfer-Encoding: chunked首部, 那么Content-Length將被忽略