HTTP
Antwortkodierungen und Komprimierung

HTTP-Komprimierung

Der HTTP-Nachrichtentext kann komprimiert werden (seit HTTP / 1.1). Entweder komprimiert der Server die Anforderung und fügt einen Content-Encoding Header hinzu oder durch einen Proxy-Assistenten und fügt einen Transfer-Encoding Header hinzu.

Ein Client kann einen Accept-Encoding Anforderungsheader senden, um anzugeben, welche Codierungen er akzeptiert.

Die am häufigsten verwendeten Kodierungen sind:

• gzip - Deflate-Algorithmus (LZ77) mit CRC32-Prüfsumme, implementiert im Komprimierungsprogramm "gzip" ( RFC1952 )
• deflate - Datenformat "Zlib" ( RFC1950 ), Deflate-Algorithmus (Hybrid LZ77 und Huffman) mit Adler32-Prüfsumme

Mehrere Komprimierungsmethoden

Es ist möglich, den Inhalt einer HTTP-Antwortnachricht mehr als einmal zu komprimieren. Die Kodierungsnamen sollten dann in der Reihenfolge, in der sie angewendet wurden, durch ein Komma getrennt werden. Wenn zum Beispiel eine Nachricht über deflate und dann gzip komprimiert wurde, sollte der Header folgendermaßen aussehen:

Content-Encoding: deflate, gzip

Mehrere Content-Encoding Header sind ebenfalls gültig, werden jedoch nicht empfohlen:

Content-Encoding: deflate
Content-Encoding: gzip

gzip-Komprimierung

Der Client sendet zuerst eine Anforderung mit einem Accept-Encoding Header, der angibt, dass er gzip unterstützt:

GET / HTTP/1.1\r\n
Host: www.google.com\r\n
Accept-Encoding: gzip, deflate\r\n
\r\n

Der Server kann dann eine Antwort mit einem komprimierten Antworttext und einem Content-Encoding Header senden, der angibt, dass die gzip-Codierung verwendet wurde

HTTP/1.1 200 OK\r\n
Content-Encoding: gzip\r\n
Content-Length: XX\r\n
\r\n
... compressed content ...