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:
- 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).
- 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
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:
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
:
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
- HTTP Inhaltsverhandlung
- Ein Header mit dem Ergebnis der Inhaltsverhandlung:
Content-Encoding
- Andere ähnliche Header:
TE
,Accept
,Accept-Language
- Brotli-Komprimierung
- GZip-Komprimierung
- Zstandard-Komprimierung