Accept-Encoding header
Baseline
Weitgehend verfügbar
*
Diese Funktion ist gut etabliert und funktioniert auf vielen Geräten und in vielen Browserversionen. Sie ist seit Juli 2015 browserübergreifend verfügbar.
* Einige Teile dieser Funktion werden möglicherweise unterschiedlich gut unterstützt.
Der HTTP-Accept-Encoding-Request- und Response-Header gibt die Inhaltskodierung (üblicherweise einen Komprimierungsalgorithmus) an, die der Sender verstehen kann.
In Requests verwendet der Server die Content Negotiation, um einen der Kodierungsvorschläge des Clients auszuwählen, und informiert den Client mit dem Response-Header Content-Encoding über diese Wahl.
In Responses liefert er Informationen darüber, welche Inhaltskodierungen der Server in Nachrichten an die angeforderte Ressource verstehen kann, sodass die Kodierung in nachfolgenden Requests an die Ressource verwendet werden kann.
Beispielsweise ist Accept-Encoding in einer 415 Unsupported Media Type-Response enthalten, wenn ein Request an eine Ressource (z. B. PUT) eine nicht unterstützte Kodierung verwendet hat.
Selbst wenn Client und Server dieselben Komprimierungsalgorithmen unterstützen, kann der Server entscheiden, den Body einer Response nicht zu komprimieren, wenn auch der Wert identity akzeptabel ist.
Dies tritt in zwei häufigen Fällen auf:
- Die Daten sind bereits komprimiert, was bedeutet, dass eine zweite Komprimierungsrunde die Größe der übertragenen Daten nicht verringert und die Größe des Inhalts in einigen Fällen sogar erhöhen kann. Dies gilt für vorkomprimierte Bildformate (beispielsweise JPEG).
- Der Server ist überlastet und kann keine Rechenressourcen für die Komprimierung bereitstellen. Microsoft empfiehlt beispielsweise, nicht zu komprimieren, wenn ein Server mehr als 80 % seiner Rechenleistung nutzt.
Solange die Direktiven identity;q=0 oder *;q=0 den Wert identity, 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 offizieller Inhaltskodierungen.
Die Kodierungen bzip und bzip2 sind nicht standardisiert, können jedoch in einigen Fällen verwendet werden, insbesondere zur Unterstützung älterer Systeme.
| Header-Typ | Request-Header, Response-Header |
|---|---|
| Verbotener Request-Header | Ja |
Syntax
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 Komprimierungsformat, das die Lempel-Ziv-Kodierung (LZ77) mit einer 32-Bit-CRC verwendet.
compress-
Ein Komprimierungsformat, das den Lempel-Ziv-Welch-Algorithmus (LZW) verwendet.
deflate-
Ein Komprimierungsformat, das die zlib-Struktur mit dem Komprimierungsalgorithmus deflate verwendet.
br-
Ein Komprimierungsformat, das den Brotli-Algorithmus verwendet.
zstd-
Ein Komprimierungsformat, das den Zstandard-Algorithmus verwendet.
dcb-
Ein Format, das den Algorithmus Dictionary-Compressed Brotli verwendet. Siehe Compression Dictionary Transport.
dcz-
Ein Format, das den Algorithmus Dictionary-Compressed Zstandard verwendet. Siehe Compression Dictionary Transport.
identity-
Gibt die Identitätsfunktion an (d.h. ohne Änderung oder Komprimierung). Dieser Wert wird immer als akzeptabel betrachtet, auch wenn er weggelassen wird.
*(Platzhalter)-
Entspricht jeder Inhaltskodierung, die nicht bereits im Header aufgeführt ist. Dies ist der Standardwert, wenn der Header nicht vorhanden ist. Diese Direktive legt nicht nahe, dass ein Algorithmus unterstützt wird, sondern gibt an, dass keine Präferenz ausgedrückt wird.
;q=(qvalue-Gewichtung)-
Jeder Wert wird in eine Präferenzreihenfolge gebracht, die mithilfe eines relativen Qualitätswerts, Gewichtung genannt, ausgedrückt wird.
Beispiele
Standardwerte für Accept-Encoding
Die Browser-Navigation weist üblicherweise den folgenden Wert für den Accept-Encoding-Request-Header auf:
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ätswerts zwischen 0 (niedrigste Priorität) und 1 (höchste Priorität).
Die Brotli-Komprimierung wird mit 1.0 gewichtet, wodurch br zur ersten Wahl des Clients wird, gefolgt von gzip mit einer Priorität von 0.8 und anschließend jeder anderen Inhaltskodierung mit 0.1:
Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
Spezifikationen
| Spezifikation |
|---|
| HTTP Semantics # field.accept-encoding |
Browser-Kompatibilität
Siehe auch
415 Unsupported Media Type- HTTP-Content Negotiation
- Ein Header mit dem Ergebnis der Content Negotiation:
Content-Encoding - Weitere ähnliche Header:
TE,Accept,Accept-Language - Brotli-Komprimierung
- GZip-Komprimierung
- Zstandard-Komprimierung
- Leitfaden zu Compression Dictionary Transport