Chunked transfer encoding

L'introduction de l'encodage de transfert en bloc du protocole HTTP 1.1 a fourni un certain nombre d'avantages :

• Permettre à un serveur de maintenir une connexion HTTP persistante pour un contenu généré dynamiquement.
• Permettre à l'expéditeur d'envoyer des en-têtes supplémentaires après le corps du message. Sans l'encodage de transfert en bloc, l'expéditeur devrait tamponner le contenu jusqu'à ce qu'il soit complété afin de calculer une valeur et l'envoyer avant le contenu.

HTTP/1.1 200 OK\r\n
Content-Type: text/plain\r\n
Transfer-Encoding: chunked\r\n
\r\n
27\r\n
Voici les données du premier morceau\r\n\r\n
1C\r\n
et voici un second morceau\r\n\r\n
20\r\n
et voici deux derniers morceaux \r\n
12\r\n
sans saut de ligne\r\n
0\r\n
\r\n

Les deux premiers morceaux dans l'exemple ci-dessus contiennent les caractères \r\n de sauts de lignes au format Microsoft (\n est utilisé pour le format Unix et généralement pour les protocoles TCP/IP, \r pour le format Mac). Ces derniers n'ont absolument aucune utilité au niveau du découpage des morceaux… ils font partie des données transmises.

"Voici les données du premier morceau\r\n"     (39 chars => hex: 0x27)
"et voici un second morceau\r\n"               (28 chars => hex: 0x1C)
"et voici deux derniers morceaux "             (32 chars => hex: 0x20)
"sans saut de ligne"                           (18 chars => hex: 0x12)

La réponse se termine par un morceau de longueur zéro "0\r\n" suivi par "\r\n".

Voici les données du premier morceau
et voici un second morceau
et voici deux derniers morceaux sans saut de ligne

• Pour plus d'information, voir la RFC 7230^[2], et plus particulièrement la section 4.1 Transfer Codings.

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Chunked transfer encoding » (voir la liste des auteurs).

• Portail d’Internet
• Portail de l’informatique