Content-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 Content-Encoding Darstellungsheader listet die Kodierungen und die Reihenfolge auf, in der sie auf eine Ressource angewendet wurden. Dadurch erfährt der Empfänger, wie die Daten dekodiert werden müssen, um das ursprüngliche Inhaltsformat zu erhalten, wie im Content-Type-Header beschrieben. Die Inhaltskodierung wird hauptsächlich verwendet, um Inhalte zu komprimieren, ohne Informationen über den ursprünglichen Medientyp zu verlieren.

Server sollten Daten so weit wie möglich komprimieren und Inhaltskodierung verwenden, wo es angemessen ist. Die Komprimierung bereits komprimierter Medientypen, wie .zip oder .jpeg, ist in der Regel nicht angemessen, da sie die Dateigröße erhöhen kann. Wenn das ursprüngliche Medium bereits kodiert ist (z.B. als .zip-Datei), wird diese Information nicht im Content-Encoding-Header angegeben.

Wenn der Content-Encoding-Header vorhanden ist, beziehen sich andere Metadaten (z.B. Content-Length) auf die kodierte Form der Daten, nicht auf die ursprüngliche Ressource, es sei denn, es wird explizit angegeben. Die Inhaltskodierung unterscheidet sich von Transfer-Encoding darin, dass Transfer-Encoding behandelt, wie HTTP-Nachrichten selbst über das Netzwerk auf Hop-by-Hop-Basis übertragen werden.

Header-Typ Darstellungsheader
Verbotener Anforderungsheader Nein

Syntax

http
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br
Content-Encoding: zstd

// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip

Direktiven

gzip

Ein Format, das die Lempel-Ziv-Kodierung (LZ77) mit einer 32-Bit-CRC verwendet. Dies ist das ursprüngliche Format des UNIX gzip-Programms. Der HTTP/1.1-Standard empfiehlt auch, dass Server, die diese Inhaltskodierung unterstützen, x-gzip als Alias erkennen, aus Kompatibilitätsgründen.

compress

Ein Format, das den Lempel-Ziv-Welch (LZW)-Algorithmus verwendet. Der Wertname stammt von dem UNIX compress-Programm, das diesen Algorithmus implementierte. Wie das compress-Programm, das aus den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltskodierung heute von vielen Browsern nicht mehr verwendet, teilweise wegen eines Patentproblems (es lief 2003 aus).

deflate

Verwendung der zlib-Struktur (definiert in RFC 1950) mit dem deflate-Komprimierungsalgorithmus (definiert in RFC 1951).

br

Ein Format, das die Brotli-Algorithmusstruktur (definiert in RFC 7932) verwendet.

zstd

Ein Format, das die Zstandard-Algorithmusstruktur (definiert in RFC 8878) verwendet.

Beispiele

Komprimierung mit gzip

Auf der Clientseite können Sie eine Liste von Komprimierungsschemata angeben, die mit einer HTTP-Anfrage gesendet werden. Der Accept-Encoding-Header wird zur Aushandlung der Inhaltskodierung verwendet.

http
Accept-Encoding: gzip, deflate

Der Server antwortet mit dem verwendeten Schema, das durch den Content-Encoding-Antwortheader angegeben wird.

http
Content-Encoding: gzip

Ob ein Server Komprimierungsmethoden verwendet, die vom Client angefordert werden, hängt von der Serverkonfiguration und den Fähigkeiten ab.

Spezifikationen

Specification
HTTP Semantics
# field.content-encoding

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch