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.

* Some parts of this feature may have varying levels of support.

Der HTTP-Accept-Encoding Request-Header und Response-Header gibt an, welche Inhaltskodierung (normalerweise ein Kompressionsalgorithmus) der Absender verstehen kann. Bei Anfragen verwendet der Server die Inhaltsverhandlung, um einen der vom Client vorgeschlagenen Kodierungsverfahren auszuwählen und teilt dem Client die Wahl mit dem Content-Encoding-Response-Header mit. In Antworten gibt er an, welche Inhaltskodierungen der Server in Nachrichten zur angeforderten Ressource verstehen kann, sodass die Kodierung in nachfolgenden Anfragen an die Ressource verwendet werden kann. Zum Beispiel wird Accept-Encoding in einer 415 Unsupported Media Type-Antwort enthalten, wenn eine Anfrage an eine Ressource (z.B. PUT) eine nicht unterstützte Kodierung verwendet hat.

Selbst wenn sowohl der Client als auch der Server dieselben Kompressionsalgorithmen unterstützen, kann der Server entscheiden, den Body einer Antwort nicht zu komprimieren, wenn der Wert identity ebenfalls akzeptabel ist. Dies tritt in zwei häufigen Fällen auf:

  1. Die Daten sind bereits komprimiert, was bedeutet, dass eine zweite Kompression die übertragene Datenmenge nicht reduziert und in einigen Fällen sogar die Größe des Inhalts erhöhen kann. Dies gilt für vorab komprimierte Bildformate (JPEG zum Beispiel).
  2. Der Server ist überlastet und kann keine Rechneressourcen bereitstellen, um die Kompression durchzuführen. Beispielsweise empfiehlt Microsoft, nicht zu komprimieren, wenn ein Server mehr als 80 % seiner Rechenleistung verbraucht.

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

Hinweis: Die IANA führt eine Liste der offiziellen Inhaltskodierungen. Die Kodierungen bzip und bzip2 sind nicht standardisiert, können aber in einigen Fällen, insbesondere zur Unterstützung von Altsystemen, verwendet werden.

Header-Typ Request-Header, Response-Header
Verbotener Request-Header Ja

Syntax

http
Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: zstd
Accept-Encoding: dcb
Accept-Encoding: dcz
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 Kompressionsformat, das die Lempel-Ziv-Codierung (LZ77) mit einem 32-Bit-CRC verwendet.

compress

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

deflate

Ein Kompressionsformat, das die zlib-Struktur mit dem deflate-Kompressionsalgorithmus verwendet.

br

Ein Kompressionsformat, das den Brotli-Algorithmus verwendet.

zstd

Ein Kompressionsformat, das den Zstandard-Algorithmus verwendet.

dcb

Ein Format, das den Dictionary-Compressed Brotli-Algorithmus verwendet. Siehe Kompressionswörterbuch-Transport.

dcz

Ein Format, das den Dictionary-Compressed Zstandard-Algorithmus verwendet. Siehe Kompressionswörterbuch-Transport.

identity

Gibt die Identitätsfunktion an (d.h. ohne Veränderung oder Kompression). Dieser Wert wird immer als akzeptabel betrachtet, auch wenn er weggelassen wird.

* (Wildcard)

Passt zu jeder Inhaltskodierung, 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= (q-Werte-Gewichtung)

Jeder Wert wird in einer Reihenfolge der Präferenz mit einem relativen Qualitätswert ausgedrückt, der als Gewicht bezeichnet wird.

Beispiele

Standardwerte von Accept-Encoding

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

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

Gewichtete Accept-Encoding-Werte

Der folgende Header zeigt Accept-Encoding-Präferenzen unter Verwendung eines Qualitätswertes zwischen 0 (niedrigste Priorität) und 1 (höchste Priorität). Die Brotli-Kompression wird mit 1.0 gewichtet, was br zur ersten Wahl des Clients macht, gefolgt von gzip mit 0.8 Priorität und dann jede andere 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

Siehe auch