Content-Length首部告訴瀏覽器報文中實體主體的大小。這個大小是包含了內容編碼的，比如對檔案進行了gzip壓縮，Content-Length就是壓縮後的大小（這點對我們編寫伺服器非常重要）。除非使用了分塊編碼，否則Content-Length首部就是帶有實體主體的報文必須使用的。使用Content-Length首部是為了能夠檢測出伺服器崩潰而導致的報文截尾，並對共享持久連線的多個報文進行正確分段。

1）檢測截尾

HTTP的早期版本採用關閉連線的辦法來劃定報文的結束。但是，沒有Content-Length的話，客戶端無法區分到底是報文結束時正常的關閉連線還是報文傳輸中由於伺服器崩潰而導致的連線關閉。客戶端需要通過Content-Length來檢測報文截尾。

報文截尾的問題對快取代理伺服器來說尤為重要。如果快取伺服器收到被截尾的報文卻沒有識別出截尾的話，它可能會儲存不完整的內容並多次使用他來提供服務。快取代理伺服器通常不會為沒有顯式Content-Length首部的HTTP主體做快取，以此來減小快取已截尾報文的風險。

2）Content-Length與持久連線

Content-Length首部對於持久連結是必不可少的。如果響應通過持久連線傳送，就可能有另一條HTTP響應緊隨其後。客戶端通過Content-Length首部就可以知道報文在何處結束，下一條報文從何處開始。因為連線是持久的，客戶端無法依賴連線關閉來判斷報文的結束。

有一種情況，使用持久連線可以沒有Content-Length首部，即採用分塊編碼（chunked encoding）時。在分塊編碼的情況下，資料是分為一系列的塊來發送的，沒塊都有大小說明。哪怕伺服器在生成首部的時候不知道整個實體的大小（通常是因為實體是動態生成的），仍然可以使用分塊編碼傳輸若干已知大小的塊。