摘要： 理解HTTP協議...

• 原文：用了這么久HTTP, 你是否了解Content-Length和Transfer-Encoding ?
• 作者：樸瑞卿的博客

由Content-Length導致的問題引發的一系列思考: 前段時間開發API網關, 使用postman調試時出現了超時的情況, 經排查確定是請求數據被處理后Content-Length與實際不一致導致的問題, 故有此文.

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

• 無響應直到超時.
• 請求被截斷, 而且下一個請求解析出現錯亂.

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

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

Content-Length是如何工作的

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

如果這個長度不正確, 會發生如下情況:

Content-Length > 實際長度

如果Content-Length比實際的長度大, 服務端/客戶端讀取到消息結尾后, 會等待下一個字節, 自然會無響應直到超時.

同樣地, 在響應消息中Content-Length超過實際長度也是一樣的效果:

Content-Length < 實際長度

如果這個長度小于實際長度, 首次請求的消息會被截取, 比如參數為param=piaoruiqing, Content-Length為10, 那么這次請求的消息會被截取為: param=piao, 如圖所示:

但, 僅僅是如此嗎, 當然不, 我們再來看看第二次請求會發生什么讓人意外的事情, 如圖:

連續的兩次請求, 第一次消息被截斷, 而第二次沒有發生預期的截斷, 而是服務端拋出了異常: Request method 'ruiqingPOST' not supported.刺不刺激 (ﾉ)ﾟДﾟ( )

那 ruiqingPOST是個什么神仙方法??? 此時, 憑著多年開發(DEBUG)經驗練就的敏感度, 我們大致可以猜出, 上一次請求被截取剩下的消息, 在這次請求出現了. 掏出wireshark來驗證一下, 如圖:

導致這種情況的原因就是開啟了Connection:keep-alive, 如果使用Connection:close, 所產生的現象就是每一次的請求都被截斷, 但不會產生解析混亂(如將上一次剩下的消息拼接到后續的請求消息中).

不確定Content-Length的值怎么辦

Content-Length首部指示出報文中實體主體的字節大小. 但如在請求處理完成前無法獲取消息長度, 我們就無法明確指定Content-Length, 此時應該使用Transfer-Encoding: chunked

什么是Transfer-Encoding: chunked

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

Transfer-Encoding: chunked是如何工作的

接下來我們用一個下載文件的例子, 來探討Transfer-Encoding: chunked是如何工作的. 服務端代碼如下:

使用postman發起請求, wireshark抓包查看, 如圖:

在wireshark中可以很清晰地看到chunked的數據, 其結構大致是: 返回的消息被分為多個數據塊, 每個數據塊有兩部分, 長度 + 數據, 這兩部分都以CRLF(即rn)結尾. 而終止塊是一個特殊的數據塊, 其長度為0, 如圖:

如此, 即完成了分塊編碼. 其主要應用于如下場景, 即要傳輸大量的數據, 但是在請求在沒有被處理完之前響應的長度是無法獲得的. 例如, 當需要用從數據庫中查詢獲得的數據生成一個大的HTML表格、需要傳輸大量的圖片等.

• Content-Length如果存在且生效, 必須是正確的, 否則會發生異常.(大于實際值會超時, 小于實際值會截斷并可能導致后續的數據解析混亂)
• 如果報文中包含Transfer-Encoding: chunked首部, 那么Content-Length將被忽略.

參考

• https://developer.mozilla.org
• 《HTTP權威指南》

版權聲明

本文發布于樸瑞卿的博客, 允許非商業用途轉載, 但轉載必須保留原作者樸瑞卿 及鏈接:https://blog.piaoruiqing.com. 如有授權方面的協商或合作, 請聯系郵箱: piaoruiqing@gmail.com.

關于Fundebug

Fundebug專注于JavaScript、微信小程序、微信小游戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了20億+錯誤事件，付費客戶有陽光保險、核桃編程、荔枝FM、掌門1對1、微脈、青團社等眾多品牌企業。歡迎大家免費試用！

總結

以上是生活随笔為你收集整理的http下载异常_用了这么久HTTP, 你是否了解Content-Length?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。