Content Encoding

Content Encoding

Copyright © Unsplash / Georg Bommeli

Was ist Content Encoding?

Content Encoding findet Anwendung fĂŒr die VerschlĂŒsselungen von Inhalten vor dem Versenden bei HTTP-Anwendungen. Der Server komprimiert in diesem Fall beispielsweise ein umfangreiches HTML-Dokument, bevor es an den Client gesendet wird. Der Inhalt wird durch den Server so verschlĂŒsselt, dass unbefugte Dritte den Inhalt des Dokuments nicht angezeigt bekommen. Die entsprechenden VerschlĂŒsselungsarten (Kodierungen) werden auf den Inhalt des Absenders angewandt. Sobald dieser Inhalt wieder entschlĂŒsselt (dekodiert) wurde, werden diese Daten wie ĂŒblich an den EmpfĂ€nger als sogenannte Entity-Bodies gesendet.

Beschreibung

FĂŒr die Inhaltskodierung wird das Entity-Header-Feld als Modifikator (Bestimmungswert) fĂŒr den Medientyp verwendet. Ist dieser Wert vorhanden, gibt er an, welche zusĂ€tzlichen Inhaltskodierungen auf den Entity-Body angewendet wurden und welche Dekodierungsmechanismen benutzt werden mĂŒssen, um den Medientyp zu erhalten, auf den das Header-Feld verweist.

Das Content Encoding ist somit ein Merkmal einer Dateneinheit, die durch den Request-URI identifiziert wird. Normalerweise wird der Entity-Body mit dieser Kodierung gespeichert und nur vor dem Rendern oder einer analogen Verwendung wieder dekodiert. Ein nicht transparenter Proxy-Server kann jedoch die Inhaltskodierung modifizieren, wenn bekannt ist, dass die neue Kodierung fĂŒr den EmpfĂ€nger akzeptabel ist (es sei denn, die Cache-Steueranweisung “no-transform” ist in der Nachricht vorhanden).

Im Fall, dass die Inhaltskodierung einer Dateneinheit nicht identisch ist, muss die Antwort einen Content-Encoding-Header enthalten, der die verwendete(n) Nicht-IdentitĂ€tsinhaltskodierung(en) auffĂŒhrt. Liegt dies vor und eine Inhaltskodierung ist nicht fĂŒr eine Anforderungsnachricht des Ursprungsservers akzeptabel, so sollte der Server mit dem Statuscode 415 antworten (nicht unterstĂŒtzter Medientyp).

Mehrere Dateneinheiten

Wurden auf einer Dateneinheit mehrere Kodierungen angewandt, mĂŒssen die Inhaltskodierungen in der Reihenfolge aufgefĂŒhrt sein, in der sie angewendet wurden. ZusĂ€tzliche Informationen zu den Kodierungsparametern können von anderen Entity-Header-Feldern bereitgestellt werden, die nicht in dieser Spezifikation definiert sind.

Content Encoding Prozess

Der Prozess stellt sich wie folgt dar:

1. Ein Webserver generiert eine ursprĂŒngliche Antwortnachricht mit den ursprĂŒnglichen Kopfzeilen “Content-Type” und “Content-Lenght”.

2. Ein Content Encoding Server (möglicherweise der Ursprungsserver oder ein Downstream-Proxy) erstellt eine kodierte Nachricht. Die verschlĂŒsselte Nachricht hat den gleichen Inhaltstyp, aber (wenn zum Beispiel der Hauptteil komprimiert ist) eine andere InhaltslĂ€nge. Der Content Encoding Server fĂŒgt der kodierten Nachricht einen sog. Content-Encoding-Header hinzu, sodass eine empfangende Anwendung diese dekodieren kann.

3. Ein Empfangsprogramm erhĂ€lt die verschlĂŒsselte Nachricht, dekodiert sie und erhĂ€lt anschließend das Original.

Richtlinien

gzip-Format

Ein Format, das die Lempel-Ziv-Codierung (LZ77) verwendet, mit einem 32-Bit-CRC. Dies ist das ursprĂŒngliche Format des UNIX-gzip-Programms. Der HTTP / 1.1-Standard empfiehlt außerdem, dass die Server, die diese Inhaltskodierung unterstĂŒtzen, x-gzip aus KompatibilitĂ€tsgrĂŒnden als Alisasnamen erkennen.

compress-Format

Ein Format, das den Lempel-Ziv-Welch-Algorithmus (LZW) verwendet. Der Wertname wurde aus dem UNIX-Kompressionsprogramm ĂŒbernommen, das diesen Algorithmus implementierte. Wie das Kompressionsprogramm, das in den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltskodierung heutzutage von vielen Browsern nicht verwendet, teilweise aufgrund eines Patentproblems (seit 2003 abgelaufen).

Entleerung

Verwendung der sogenannten zlib-Struktur (definiert in RFC 1950) mit dem Deflate-Kompressionsalgorithmus (definiert in RFC 1951).

IdentitÀt

Gibt die IdentitĂ€tsfunktionen an (d. h. keine Komprimierung oder Modifikation). Dieses Token wird, sofern nicht ausdrĂŒcklich angegeben, immer als akzeptabel betrachtet.

br-Format

Hier handelt es sich um ein Format, das den Brotli-Algorithmus verwendet.

Fazit

Das Content Encoding wird fĂŒr die Komprimierung eines Dokumentes verwendet, ohne die eigentliche IdentitĂ€t des zugrunde liegenden Medientyps zu verlieren.


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte