Transfer-Encoding
Utilisation
L’en-tête Transfer-Encoding est un en-tête saut par saut qui décrit la façon dont le corps du message est encodé pour le segment de connexion courant. Chaque intermédiaire (proxy, passerelle) décode le codage de transfert, traite le message, puis le réencode avant de le transmettre au nœud suivant.
La valeur la plus courante est chunked, qui permet à un serveur de commencer à diffuser une réponse en flux avant de connaître la Content-Length totale. Le serveur découpe le corps en fragments, chacun précédé d’un indicateur de taille. Un fragment de longueur nulle signale la fin du message.
Contrairement à Content-Encoding, qui applique une compression de bout en bout à la ressource elle-même, Transfer-Encoding n’opère qu’entre deux nœuds adjacents. Un serveur qui envoie une ressource compressée en gzip sur une connexion chunked utilise Content-Encoding pour la compression et Transfer-Encoding pour le découpage en fragments.
Lorsque Transfer-Encoding apparaît dans la réponse à une requête HTTP HEAD, la valeur reflète l’encodage que le serveur appliquerait au corps dans une réponse GET correspondante.
Remarque
Content-Encoding est de bout en bout : la ressource elle-même est compressée (par exemple en gzip) et chaque destinataire décode la charge utile. Transfer-Encoding est saut par saut : l’encodage est appliqué pour le transport entre deux nœuds adjacents et retiré à chaque saut. Une réponse peut porter les deux en-têtes à la fois, Content-Encoding servant à compresser la ressource et Transfer-Encoding à la livraison en fragments.
Remarque
L’en-tête HTTP Transfer-Encoding n’a aucun rapport avec le Content-Transfer-Encoding du courrier électronique, qui gère l’encodage MIME tel que base64 ou quoted-printable pour les corps de courriels.
Remarque
L’en-tête Transfer-Encoding est interdit en HTTP/2 et HTTP/3. Ces protocoles fournissent leurs propres mécanismes de découpage en trames, ce qui rend inutile un encodage au niveau du transfert.
chunked
La directive chunked découpe le corps du message en une série de fragments. Chaque fragment commence par sa taille en hexadécimal, suivie des données du fragment. Un fragment final de taille zéro termine le message. L’en-tête Trailer liste les champs éventuellement ajoutés après le dernier fragment.
compress
La directive compress applique la compression Lempel-Ziv-Welch (LZW). Cet encodage est rarement utilisé dans les déploiements modernes.
deflate
La directive deflate applique la compression zlib avec l’algorithme deflate.
gzip
La directive gzip applique le codage Lempel-Ziv (LZ77) avec une somme de contrôle CRC 32 bits. C’est le même algorithme que celui du format de fichier gzip ; il est largement pris en charge par les implémentations HTTP.
Exemple
Un serveur envoie une réponse chunked. L’absence d’en-tête Content-Length indique que le serveur diffuse le corps par morceaux.
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
0\r\n
\r\nPlusieurs codages de transfert sont appliqués dans l’ordre. Dans cette réponse, le corps est d’abord compressé en gzip, puis découpé en fragments pour la transmission.
Transfer-Encoding: gzip, chunked