最近在開發(fā)時(shí)，發(fā)現(xiàn)客戶端的文件上傳有兩種頭：

第一種是帶有Content-Length的：

帶有content-length的上傳

第二種是不帶Content-Length的：

不帶content-length的上傳

一般來講，上傳文件需要在請(qǐng)求頭中帶上content-length，以告知服務(wù)端需要接受的數(shù)據(jù)包大小。

但HTTP協(xié)議中提供了另一種方式，來約定上傳邊界。就是以分塊編碼形式來發(fā)送數(shù)據(jù)。
數(shù)據(jù)發(fā)送方式在headers.Transfer-Encoding中表現(xiàn)。

詳見：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Transfer-Encoding

文中指出：

（Transfer-Encoding: chunked時(shí)）數(shù)據(jù)以一系列分塊的形式進(jìn)行發(fā)送。 Content-Length 首部在這種情況下不被發(fā)送。。在每一個(gè)分塊的開頭需要添加當(dāng)前分塊的長度，以十六進(jìn)制的形式表示，后面緊跟著 '\r\n' ，之后是分塊本身，后面也是'\r\n' 。終止塊是一個(gè)常規(guī)的分塊，不同之處在于其長度為0。終止塊后面是一個(gè)掛載（trailer），由一系列（或者為空）的實(shí)體消息首部構(gòu)成。

分塊編碼主要應(yīng)用于如下場(chǎng)景，即要傳輸大量的數(shù)據(jù)，但是在請(qǐng)求在沒有被處理完之前響應(yīng)的長度是無法獲得的。例如，當(dāng)需要用從數(shù)據(jù)庫中查詢獲得的數(shù)據(jù)生成一個(gè)大的HTML表格的時(shí)候，或者需要傳輸大量的圖片的時(shí)候。

對(duì)服務(wù)端來說，應(yīng)該注意支持這種上傳方式。
對(duì)nodejs服務(wù)端來說，formidable這種庫默認(rèn)支持分塊編碼上傳。但仍需考慮到經(jīng)過代理、CDN時(shí)，上傳可能出現(xiàn)的異常。