HTTP
Svarskodningar och komprimering

HTTP-komprimering

HTTP-meddelandekroppen kan komprimeras (sedan HTTP / 1.1). Antingen av servern komprimerar begäran och lägger till en rubrik för Content-Encoding , eller genom att en proxy gör och lägger till en rubrik för Transfer-Encoding .

En klient kan skicka en Accept-Encoding begäranhuvud för att ange vilka kodningar den accepterar.

De mest använda kodningarna är:

• gzip - deflate algoritm (LZ77) med CRC32-kontrollsumma implementerat i "gzip" -filens komprimeringsprogram ( RFC1952 )
• deflate - "zlib" dataformat ( RFC1950 ), deflate algoritm (hybrid LZ77 och Huffman) med Adler32-kontrollsumma

Flera komprimeringsmetoder

Det är möjligt att komprimera en HTTP-svarmeddelandekropp mer än en gång. Kodningsnamnen ska sedan separeras med ett komma i den ordning de tillämpades. Om till exempel ett meddelande komprimeras via deflate och sedan gzip, ska rubriken se ut så här:

Content-Encoding: deflate, gzip

Flera rubriker för Content-Encoding är också giltiga, men rekommenderas inte:

Content-Encoding: deflate
Content-Encoding: gzip

gzip-komprimering

Klienten skickar först en begäran med en Accept-Encoding rubrik som indikerar att den stöder gzip:

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

Servern kan sedan skicka ett svar med en komprimerad svarskropp och en rubrik för Content-Encoding som anger att gzip-kodning användes ::

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