Transfer-Encoding 頭部

Baseline 已廣泛支援

此特性已相當成熟,可在許多裝置和瀏覽器版本上使用。自 ⁨2015 年 7 月⁩以來,各瀏覽器均已提供此特性。

HTTP Transfer-Encoding 請求響應頭部指定了用於在網路節點之間傳輸訊息的編碼形式。

Transfer-Encoding 是一個逐跳頭部,應用於兩個節點之間的訊息,而不是資源本身。多節點連線的每個段都可以使用不同的Transfer-Encoding值。如果你想在整個連線中壓縮資料,請改用端到端Content-Encoding頭部。

實際上,這個頭部很少使用,在這些情況下,它幾乎總是與chunked一起使用。

也就是說,規範指出,當訊息中存在此頭部時,它表示該跳中對訊息使用的壓縮,和/或訊息是否已分塊。例如,Transfer-Encoding: gzip, chunked表示內容已使用 gzip 編碼壓縮,然後在使用分塊編碼形成訊息正文時進行分塊。

在對 HEAD 請求的響應中,該頭部是可選的,因為這些訊息沒有正文,因此沒有傳輸編碼。當存在時,它表示如果相應的 GET 請求不包含首選的 Transfer-Encoding,那麼它將應用於該 GET 訊息的響應值。

警告: HTTP/2 不允許所有使用 Transfer-Encoding 頭部的情況。HTTP/2 及更高版本提供了比分塊傳輸更高效的資料流機制。在 HTTP/2 中使用此頭部很可能導致特定的協議錯誤

頭型別 請求頭部響應頭部內容頭部
禁止請求頭

語法

http
Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip

// Several values can be listed, separated by a comma
Transfer-Encoding: gzip, chunked

指令

分塊(chunked)

資料以一系列“塊”的形式傳送。內容可以以未知大小的流形式傳輸,作為一系列長度分隔的緩衝區,以便傳送方可以保持連線開啟,並讓接收方知道何時已收到整個訊息。Content-Length 頭部必須省略。在每個塊的開頭,一串十六進位制數字表示塊資料的大小(以八位位元組為單位),後跟 \r\n,然後是塊本身,再後跟另一個 \r\n。終止塊是零長度的塊。

壓縮(compress)

一種使用 Lempel-Ziv-Welch (LZW) 演算法的格式。該值名稱取自實現此演算法的 UNIX compress 程式。就像 compress 程式已從大多數 UNIX 發行版中消失一樣,這種內容編碼如今幾乎沒有瀏覽器使用,部分原因是專利問題(已於 2003 年到期)。

解壓縮(deflate)

使用 zlib 結構(在 RFC 1950 中定義),以及 deflate 壓縮演算法(在 RFC 1951 中定義)。

gzip

一種使用 Lempel-Ziv 編碼 (LZ77) 的格式,帶有 32 位 CRC。這最初是 UNIX gzip 程式的格式。HTTP/1.1 標準還建議支援此內容編碼的伺服器應識別 x-gzip 作為別名,以實現相容性。

示例

帶分塊編碼的響應

當向客戶端傳送大量資料且在請求完全處理之前可能不知道響應的總大小時,分塊編碼非常有用。例如,當生成資料庫查詢產生的大型 HTML 表格或傳輸大型影像時。分塊響應如下所示

http
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
11\r\n
Developer Network\r\n
0\r\n
\r\n

規範

規範
HTTP/1.1
# field.transfer-encoding

瀏覽器相容性

另見