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.

Der HTTP-Content-Encoding-Darstellungs-Header listet die Kodierungen und deren Reihenfolge auf, die auf eine Ressource angewendet wurden. Dies gibt dem Empfänger die Möglichkeit zu verstehen, wie die Daten dekodiert werden müssen, um das ursprüngliche Inhaltsformat zu erhalten, das im Content-Type-Header beschrieben ist. Die Inhaltskodierung wird hauptsächlich verwendet, um Inhalte zu komprimieren, ohne Informationen über den ursprünglichen Medientyp zu verlieren.

Server sollten die Daten so weit wie möglich komprimieren und die Inhaltskodierung dort verwenden, wo es angemessen ist. Das erneute Komprimieren bereits komprimierter Medientypen, wie .zip oder .jpeg, ist normalerweise nicht angebracht, da dies 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 aufgenommen.

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 ausdrücklich angegeben. Die Inhaltskodierung unterscheidet sich von Transfer-Encoding darin, dass Transfer-Encoding bestimmt, wie HTTP-Nachrichten selbst netzwerkübergreifend auf einer Hop-by-Hop-Basis übertragen werden.

Header-Typ Darstellungs-Header
Verbotener Header-Name 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 einem 32-Bit-CRC verwendet. Dies ist das ursprüngliche Format des UNIX-Programms gzip. Der HTTP/1.1-Standard empfiehlt außerdem, dass Server, die diese Inhaltskodierung unterstützen, x-gzip als Alias erkennen sollten, um die Kompatibilität zu gewährleisten.

compress

Ein Format, das den Lempel-Ziv-Welch (LZW) Algorithmus verwendet. Der Wertename stammt vom UNIX-Programm compress, das diesen Algorithmus implementiert hat. Wie das Komprimierungsprogramm, das aus den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltskodierung heute von vielen Browsern nicht mehr verwendet, teilweise wegen eines Patents, das 2003 abgelaufen ist.

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 Client-Seite können Sie eine Liste von Komprimierungsmethoden 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-Antwort-Header angegeben wird.

http
Content-Encoding: gzip

Ob ein Server die vom Client angeforderten Komprimierungsmethoden verwendet, hängt von der Konfiguration und den Fähigkeiten des Servers ab.

Spezifikationen

Specification
HTTP Semantics
# field.content-encoding

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch