Accept-Encoding

Der HTTP-Accept-Encoding-Request-Header gibt die Inhaltskodierung (in der Regel ein Komprimierungsalgorithmus) an, die der Client verstehen kann. Der Server verwendet die Inhaltsverhandlung, um einen der Vorschläge auszuwählen, und informiert den Client über diese Wahl mit dem Content-Encoding-Response-Header.

Selbst wenn sowohl der Client als auch der Server dieselben Komprimierungsalgorithmen unterstützen, kann der Server entscheiden, den Inhalt eines Antwortkörpers nicht zu komprimieren, wenn auch der identity-Wert akzeptabel ist. Dies geschieht in zwei häufigen Fällen:

  1. Die Daten sind bereits komprimiert, was bedeutet, dass eine zweite Komprimierungsrunde die Größe der übertragenen Daten nicht verringert und in manchen Fällen die Größe des Inhalts tatsächlich erhöhen kann. Dies gilt für vorab komprimierte Bildformate (zum Beispiel JPEG).
  2. Der Server ist überlastet und kann keine Rechenressourcen für die Komprimierung bereitstellen. Beispielsweise empfiehlt Microsoft, keine Komprimierung durchzuführen, wenn ein Server mehr als 80 % seiner Rechenleistung nutzt.

Solange die Anweisungen identity;q=0 oder *;q=0 den identity-Wert, was keine Kodierung bedeutet, nicht ausdrücklich verbieten, darf der Server niemals einen 406 Not Acceptable-Fehler zurückgeben.

Hinweis: IANA pflegt eine Liste der offiziellen Inhaltkodierungen. Die bzip- und bzip2-Kodierungen sind nicht standardisiert, können jedoch in einigen Fällen verwendet werden, insbesondere zum Erhalt der Abwärtskompatibilität.

Header-Typ Request-Header
Verbotener Header-Name Ja

Syntax

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

// Multiple algorithms, weighted with the quality value syntax:
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

Direktiven

gzip

Ein Komprimierungsformat, das die Lempel-Ziv-Kodierung (LZ77) mit einem 32-Bit-CRC verwendet.

compress

Ein Komprimierungsformat, das den Lempel-Ziv-Welch (LZW)-Algorithmus verwendet.

deflate

Ein Komprimierungsformat, das die zlib-Struktur mit dem deflate-Komprimierungsalgorithmus verwendet.

br

Ein Komprimierungsformat, das den Brotli-Algorithmus verwendet.

zstd

Ein Komprimierungsformat, das den Zstandard-Algorithmus verwendet.

identity

Gibt die Identity-Funktion an (das heißt, ohne Modifikation oder Komprimierung). Dieser Wert wird immer als akzeptabel angesehen, selbst wenn er weggelassen wird.

*

Entspricht jeder Inhaltkodierung, die nicht bereits im Header aufgeführt ist. Dies ist der Standardwert, wenn der Header nicht vorhanden ist. Diese Direktive schlägt nicht vor, dass ein Algorithmus unterstützt wird, sondern zeigt an, dass keine Präferenz ausgedrückt wird.

;q= (qvalues-Gewichtung)

Jedem Wert wird eine Präferenzreihenfolge zugewiesen, die durch einen relativen Qualitätswert ausgedrückt wird, der als Gewichtung bezeichnet wird.

Beispiele

Standardwerte von Accept-Encoding

Die Browser-Navigation hat typischerweise den folgenden Accept-Encoding-Request-Header-Wert:

http
GET /en-US/ HTTP/2
Host: developer.mozilla.org
Accept-Encoding: gzip, deflate, br, zstd

Gewichtete Accept-Encoding Werte

Der folgende Request-Header zeigt Accept-Encoding-Präferenzen mithilfe eines Qualitätswertes zwischen 0 (niedrigste Priorität) und 1 (höchste Priorität). Die Brotli-Komprimierung hat eine Gewichtung von 1.0, was br zur ersten Wahl des Clients macht, gefolgt von gzip mit 0.8 Priorität und dann jeder anderen Inhaltskodierung mit 0.1:

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

Spezifikationen

Specification
HTTP Semantics
# field.accept-encoding

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch