HTTP
Kodowanie odpowiedzi i kompresja

Kompresja HTTP

Treść wiadomości HTTP można skompresować (od HTTP / 1.1). Albo przez serwer kompresuje żądanie i dodaje nagłówek Content-Encoding , albo przez serwer proxy robi i dodaje nagłówek Transfer-Encoding .

Klient może wysłać nagłówek żądania Accept-Encoding aby wskazać, które kodowanie akceptuje.

Najczęściej używane kodowania to:

• gzip - algorytm deflacji (LZ77) z sumą kontrolną CRC32 zaimplementowaną w programie kompresującym pliki „gzip” ( RFC1952 )
• deflate - format danych „zlib” ( RFC1950 ), algorytm deflacji (hybrydowy LZ77 i Huffman) z sumą kontrolną Adler32

Wiele metod kompresji

Można skompresować treść komunikatu odpowiedzi HTTP więcej niż raz. Nazwy kodowania należy następnie oddzielić przecinkiem w kolejności, w jakiej zostały zastosowane. Na przykład, jeśli wiadomość została skompresowana przez deflate, a następnie gzip, nagłówek powinien wyglądać następująco:

Content-Encoding: deflate, gzip

Wiele nagłówków Content-Encoding jest również poprawnych, choć nie jest to zalecane:

Content-Encoding: deflate
Content-Encoding: gzip

kompresja gzip

Klient najpierw wysyła żądanie z nagłówkiem Accept-Encoding który wskazuje, że obsługuje gzip:

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

Serwer może następnie wysłać odpowiedź ze skompresowaną Content-Encoding odpowiedzi i nagłówkiem Content-Encoding który określa, że użyto kodowania gzip:

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