在HTTP協(xié)議中，有Content-Length的詳細(xì)解讀。Content-Length用于描述HTTP消息實體的傳輸長度the transfer-length of the message-body。在HTTP協(xié)議中，消息實體長度和消息實體的傳輸長度是有區(qū)別，比如說gzip壓縮下，消息實體長度是壓縮前的長度，消息實體的傳輸長度是gzip壓縮后的長度。
在具體的HTTP交互中，客戶端是如何獲取消息長度的呢，主要基于以下幾個規(guī)則：
響應(yīng)為1xx，204，304相應(yīng)或者h(yuǎn)ead請求，則直接忽視掉消息實體內(nèi)容。
如果有Transfer-Encoding，則優(yōu)先采用Transfer-Encoding里面的方法來找到對應(yīng)的長度。比如說Chunked模式。
“如果head中有Content-Length，那么這個Content-Length既表示實體長度，又表示傳輸長度。如果實體長度和傳輸長度不相等(比如說設(shè)置了Transfer-Encoding)，那么則不能設(shè)置Content-Length。如果設(shè)置了Transfer-Encoding，那么Content-Length將被忽視”。這句話翻譯的優(yōu)點饒，其實關(guān)鍵就一點：有了Transfer-Encoding，則不能有Content-Length。
Range傳輸。不關(guān)注，沒詳細(xì)看了：)
通過服務(wù)器關(guān)閉連接能確定消息的傳輸長度。(請求端不能通過關(guān)閉連接來指明請求消息體的結(jié)束，因為這樣可以讓服務(wù)器沒有機(jī)會繼續(xù)給予響應(yīng))。這種情況主要對應(yīng)為短連接，即非keep-alive模式。
HTTP1.1必須支持chunk模式。因為當(dāng)不確定消息長度的時候，可以通過chunk機(jī)制來處理這種情況。
在包含消息內(nèi)容的header中，如果有content-length字段，那么該字段對應(yīng)的值必須完全和消息主題里面的長度匹配。
“The entity-length of a message is the length of the message-body before any transfer-codings have been applied”
也就是有chunk就不能有content-length 。
其實后面幾條幾乎可以忽視，簡單總結(jié)后如下：
1、Content-Length如果存在并且有效的話，則必須和消息內(nèi)容的傳輸長度完全一致。(經(jīng)過測試，如果過短則會截斷，過長則會導(dǎo)致超時。)
2、如果存在Transfer-Encoding(重點是chunked)，則在header中不能有Content-Length，有也會被忽視。
3、如果采用短連接，則直接可以通過服務(wù)器關(guān)閉連接來確定消息的傳輸長度。(這個很容易懂)
結(jié)合HTTP協(xié)議其他的特點，比如說Http1.1之前的不支持keep alive。那么可以得出以下結(jié)論：
1、在Http 1.0及之前版本中，content-length字段可有可無。
2、在http1.1及之后版本。如果是keep alive，則content-length和chunk必然是二選一。若是非keep alive，則和http1.0一樣。content-length可有可無。