Content-Length用于描述
在HTTP協(xié)議中瘟仿，有Content-Length的詳細(xì)解讀夫凸。Content-Length用于描述HTTP消息實(shí)體的傳輸長(zhǎng)度the transfer-length of the message-body屈尼。在HTTP協(xié)議中矮湘，消息實(shí)體長(zhǎng)度和消息實(shí)體的傳輸長(zhǎng)度是有區(qū)別览露，比如說(shuō)gzip壓縮下所灸，消息實(shí)體長(zhǎng)度是壓縮前的長(zhǎng)度丽惶，消息實(shí)體的傳輸長(zhǎng)度是gzip壓縮后的長(zhǎng)度。
1.在具體的HTTP交互中爬立，客戶端是如何獲取消息長(zhǎng)度的呢?
主要基于以下幾個(gè)規(guī)則：
* 響應(yīng)為1xx钾唬，204，304相應(yīng)或者h(yuǎn)ead請(qǐng)求，則直接忽視掉消息實(shí)體內(nèi)容知纷。
* 如果有Transfer-Encoding壤圃，則優(yōu)先采用Transfer-Encoding里面的方法來(lái)找到對(duì)應(yīng)的長(zhǎng)度。比如說(shuō)Chunked模式琅轧。
* “如果head中有Content-Length伍绳，那么這個(gè)Content-Length既表示實(shí)體長(zhǎng)度，又表示傳輸長(zhǎng)度乍桂。如果實(shí)體長(zhǎng)度和傳輸長(zhǎng)度不相等(比如說(shuō)設(shè)置了Transfer-Encoding)冲杀，那么則不能設(shè)置Content-Length。如果設(shè)置了Transfer-Encoding睹酌，那么Content-Length將被忽視”权谁。這句話翻譯的優(yōu)點(diǎn)饒，其實(shí)關(guān)鍵就一點(diǎn)：有了Transfer-Encoding憋沿，則不能有Content-Length旺芽。
* 通過(guò)服務(wù)器關(guān)閉連接能確定消息的傳輸長(zhǎng)度。(請(qǐng)求端不能通過(guò)關(guān)閉連接來(lái)指明請(qǐng)求消息體的結(jié)束辐啄，因?yàn)檫@樣可以讓服務(wù)器沒(méi)有機(jī)會(huì)繼續(xù)給予響應(yīng))采章。這種情況主要對(duì)應(yīng)為短連接，即非keep-alive模式壶辜。
HTTP1.1必須支持chunk模式悯舟。因?yàn)楫?dāng)不確定消息長(zhǎng)度的時(shí)候，可以通過(guò)chunk機(jī)制來(lái)處理這種情況砸民。
* 在包含消息內(nèi)容的header中抵怎，如果有content-length字段，那么該字段對(duì)應(yīng)的值必須完全和消息主題里面的長(zhǎng)度匹配岭参。
######其實(shí)后面幾條幾乎可以忽視反惕，簡(jiǎn)單總結(jié)后如下：
1、Content-Length如果存在并且有效的話演侯，則必須和消息內(nèi)容的傳輸長(zhǎng)度完全一致姿染。(經(jīng)過(guò)測(cè)試，如果過(guò)短則會(huì)截?cái)喟霰荆^(guò)長(zhǎng)則會(huì)導(dǎo)致超時(shí)盔粹。)
2、如果存在Transfer-Encoding(重點(diǎn)是chunked)程癌，則在header中不能有Content-Length舷嗡，有也會(huì)被忽視。
3嵌莉、如果采用短連接进萄，則直接可以通過(guò)服務(wù)器關(guān)閉連接來(lái)確定消息的傳輸長(zhǎng)度。(這個(gè)很容易懂)
######結(jié)合HTTP協(xié)議其他的特點(diǎn)，比如說(shuō)Http1.1之前的不支持keep alive中鼠。那么可以得出以下結(jié)論：
1可婶、在Http 1.0及之前版本中，content-length字段可有可無(wú)援雇。
2矛渴、在http1.1及之后版本。如果是keep alive惫搏，則content-length和chunk必然是二選一具温。若是非keep alive，則和http1.0一樣筐赔。content-length可有可無(wú)铣猩。