HTTP
Encodage des réponses et compression

Compression HTTP

Le corps du message HTTP peut être compressé (depuis HTTP / 1.1). Soit par le serveur compresse la demande et ajoute un en Content-Encoding tête Content-Encoding , soit par un proxy fait et ajoute un en Transfer-Encoding tête Transfer-Encoding .

Un client peut envoyer un en Accept-Encoding tête de demande Accept-Encoding pour indiquer les codages qu'il accepte.

Les encodages les plus couramment utilisés sont:

• algorithme gzip - deflate (LZ77) avec la somme de contrôle CRC32 implémentée dans le programme de compression du fichier "gzip" ( RFC1952 )
• dégonfler - format de données "zlib" ( RFC1950 ), algorithme de dégonflage (hybride LZ77 et Huffman) avec somme de contrôle Adler32

Méthodes de compression multiples

Il est possible de compresser plusieurs fois un corps de message de réponse HTTP. Les noms de codage doivent ensuite être séparés par une virgule dans l'ordre dans lequel ils ont été appliqués. Par exemple, si un message a été compressé via deflate puis gzip, l'en-tête devrait ressembler à ceci:

Content-Encoding: deflate, gzip

Plusieurs en Content-Encoding têtes Content-Encoding sont également valides, mais pas recommandés:

Content-Encoding: deflate
Content-Encoding: gzip

compression gzip

Le client envoie d'abord une requête avec un en Accept-Encoding tête Accept-Encoding qui indique qu'il prend en charge gzip:

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

Le serveur peut alors envoyer une réponse avec un corps de réponse compressé et un en Content-Encoding tête Content-Encoding qui spécifie que le codage gzip a été utilisé:

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