Accept-Encoding

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.

Accept-Encoding HTTP 請求標頭指示用戶端可以理解的內容編碼（通常是壓縮演算法）。伺服器使用內容協商來選擇其中一個提議，並使用 Content-Encoding 回應標頭通知用戶端該選擇。

即使用戶端和伺服器都支援相同的壓縮演算法，如果 identity 值也可接受，伺服器可能選擇不壓縮回應主體。有兩種常見情況會導致這種情況：

  • 要發送的資料已經壓縮，因此第二次壓縮不會減少傳輸的資料大小。這對於預先壓縮的圖像格式（例如 JPEG）也是如此；
  • 伺服器負載過重，無法分配計算資源來執行壓縮。例如，微軟建議如果伺服器使用超過其計算能力的 80%，就不要壓縮。

只要 identity;q=0 或 *;q=0 指令未明確禁止表示無編碼的 identity 值，伺服器就不得返回 406 Not Acceptable 錯誤。

备注：

  • IANA 註冊表維護官方內容編碼列表。
  • bzip 和 bzip2 編碼是非標準的，但在某些情況下可能會使用，包括對舊版的支援。
標頭類型 請求標頭
禁止修改的標頭 是

語法

http
Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: zstd
Accept-Encoding: identity
Accept-Encoding: *

// 使用品質值語法加權多個演算法：
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

指令

gzip

使用 Lempel-Ziv 編碼（LZ77）和 32 位元的 CRC 的壓縮格式。

compress

使用 Lempel-Ziv-Welch（LZW）演算法的壓縮格式。

deflate

使用具有 deflate 壓縮演算法的 zlib 結構的壓縮格式。

br

使用 Brotli 演算法的壓縮格式。

zstd

使用 Zstandard 演算法的壓縮格式。

identity

表示恆等函數（即無修改或壓縮）。即使省略，此值始終被視為可接受的。

*

匹配標頭中尚未列出的任何內容編碼。如果標頭不存在，則這是預設值。此指令不表示支援任何演算法，而表示不表達任何偏好。

;q=（加權 q 值）

任何值都按照使用相對 quality value（稱為 weight）表示的偏好順序。

範例

http
Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

Accept-Encoding: gzip, compress, br, zstd

Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1

規範

Specification
HTTP Semantics
# field.accept-encoding

瀏覽器相容性

BCD tables only load in the browser

參見