Baseline Widely available *
Der HTTP Content-Encoding Darstellungs-Header listet die Kodierungen und die Reihenfolge auf, in der sie auf eine Ressource angewendet wurden. Dies teilt dem Empfänger mit, wie die Daten dekodiert werden müssen, um das ursprüngliche Inhaltsformat zu erhalten, das im Content-Type-Header beschrieben ist. Content-Encoding 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 dort, wo es angemessen ist, Content-Encoding verwenden. Das Komprimieren bereits komprimierter Medientypen, wie .zip oder .jpeg, ist normalerweise nicht sinnvoll, 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 angegeben.
Wenn der Content-Encoding-Header vorhanden ist, beziehen sich andere Metadaten (z.B. Content-Length) auf die kodierte Form der Daten und nicht auf die ursprüngliche Ressource, es sei denn, es ist ausdrücklich angegeben. Content-Encoding unterscheidet sich von Transfer-Encoding, da Transfer-Encoding behandelt, wie HTTP-Nachrichten selbst über das Netzwerk auf Hop-by-Hop-Basis übertragen werden.
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br
Content-Encoding: zstd
Content-Encoding: dcb
Content-Encoding: dcz
// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip
gzip
Ein Format, das die Lempel-Ziv-Kodierung (LZ77) mit einem 32-Bit CRC verwendet. Dies ist das ursprüngliche Format des UNIX gzip Programms. Der HTTP/1.1-Standard empfiehlt auch, dass Server, die dieses Content-Encoding unterstützen, x-gzip als Alias erkennen, aus Gründen der Kompatibilität.
compress
Ein Format, das den Lempel-Ziv-Welch (LZW)-Algorithmus verwendet. Der Wertname wurde vom UNIX compress Programm übernommen, das diesen Algorithmus implementierte. Wie das compress Programm, das aus den meisten UNIX-Distributionen verschwunden ist, wird dieses Content-Encoding heute von vielen Browsern nicht mehr verwendet, teilweise aufgrund eines Patentproblems (es lief 2003 ab).
deflate
Verwendung der zlib-Struktur (definiert in RFC 1950) mit dem deflate-Kompressionsalgorithmus (definiert in RFC 1951).
br
Ein Format, das den Brotli-Algorithmus (definiert in RFC 7932) verwendet.
zstd
Ein Format, das den Zstandard-Algorithmus (definiert in RFC 8878) verwendet.
dcb Experimentell
Ein Format, das den Dictionary-Compressed Brotli Algorithmus verwendet. Siehe Compression Dictionary Transport.
dcz Experimentell
Ein Format, das den Dictionary-Compressed Zstandard Algorithmus verwendet. Siehe Compression Dictionary Transport.
Auf der Clientseite können Sie eine Liste von Komprimierungsschemata angeben, die in einer HTTP-Anfrage gesendet werden. Der Accept-Encoding-Header wird zur Aushandlung der Inhaltskodierung verwendet.
Accept-Encoding: gzip, deflate
Der Server antwortet mit dem verwendeten Schema, angezeigt durch den Content-Encoding-Antwortheader.
Ob ein Server die vom Client angeforderten Komprimierungsmethoden verwendet, hängt von der Serverkonfiguration und den Fähigkeiten ab.
Spezifikationen Browser-Kompatibilität Siehe auchRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4