HTTP
Responscoderingen en compressie

HTTP-compressie

De HTTP-berichttekst kan worden gecomprimeerd (sinds HTTP / 1.1). Ofwel door de server comprimeert het verzoek en voegt een Content-Encoding header toe, of door een proxy doet en voegt een Transfer-Encoding header toe.

Een client kan een koptekst van een Accept-Encoding verzenden om aan te geven welke coderingen hij accepteert.

De meest gebruikte coderingen zijn:

• gzip - deflate algoritme (LZ77) met CRC32 checksum geïmplementeerd in het compressieprogramma van het "gzip" bestand ( RFC1952 )
• deflate - "zlib" dataformaat ( RFC1950 ), deflate algoritme (hybride LZ77 en Huffman) met Adler32 checksum

Meerdere compressiemethoden

Het is mogelijk om meerdere keren een HTTP-antwoordbericht te comprimeren. De coderingsnamen moeten vervolgens worden gescheiden door een komma in de volgorde waarin ze zijn toegepast. Als een bericht bijvoorbeeld is gecomprimeerd via leeglopen en vervolgens gzip, ziet de koptekst er als volgt uit:

Content-Encoding: deflate, gzip

Meerdere Content-Encoding headers zijn ook geldig, maar worden niet aanbevolen:

Content-Encoding: deflate
Content-Encoding: gzip

gzip-compressie

De client verzendt eerst een aanvraag met een Accept-Encoding header die aangeeft dat het gzip ondersteunt:

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

De server kan vervolgens een antwoord verzenden met een gecomprimeerde antwoordtekst en een Content-Encoding header die aangeeft dat gzip-codering is gebruikt:

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