Content-Length
L'en-tête Content-Length détermine la longueur d'octet du corps de demande/réponse. Si vous omettez de spécifier l'en-tête Content-Length, les serveurs HTTP ajouteront implicitement un en-tête Transfer-Encoding: chunked. Les en-têtes Content-Length et Transfer-Encoding ne doivent pas être utilisés ensemble. Le destinataire n'aura aucune idée de la longueur du corps et ne pourra pas estimer le temps de fin du téléchargement. Si vous ajoutez un en-tête Content-Length, assurez-vous qu'il correspond à tout le corps en octets, s'il est incorrect, le comportement des récepteurs n'est pas défini.
L'en-tête Content-Length n'autorise pas la diffusion en continu, mais il est utile pour les fichiers binaires de grande taille dans lesquels vous souhaitez prendre en charge la diffusion partielle de contenu. Cela signifie essentiellement des téléchargements résumables, des téléchargements en pause, des téléchargements partiels et des téléchargements multi-hébergés. Cela nécessite l'utilisation d'un en-tête supplémentaire appelé Range. Cette technique est appelée Byte serving.
Transfer-Encoding
L'utilisation de Transfer-Encoding: chunked est ce qui permet le streaming dans une seule demande ou réponse. Cela signifie que les données sont transmises par chunked et n'affectent pas la représentation du contenu. Officiellement, un client HTTP est destiné à envoyer une requête avec un champ d'en-tête TE qui spécifie les types de codages de transfert que le client est prêt à accepter. Ce n'est pas toujours envoyé, mais la plupart des serveurs supposent que les clients peuvent traiter les codages chunked.
Le codage de transfert chunked fait un meilleur usage des connexions TCP persistantes, que HTTP 1.1 suppose être vrai par défaut.
Content-Encoding
Il est également possible de compresser les données CHUNKED ou non CHUNKED. Ceci est pratiquement fait via l'en-tête Content-Encoding. Notez que le Content-Length est égal à la longueur du corps après le Content-Encoding. Cela signifie que si vous avez gzippé votre réponse, le calcul de la longueur se produit après la compression. Vous devrez être en mesure de charger le corps entier en mémoire si vous voulez calculer la longueur (sauf si vous avez cette information ailleurs).
Lors de la diffusion en utilisant le codage en bloc, l'algorithme de compression doit également prendre en charge le traitement en ligne. Heureusement, gzip supporte la compression de flux. Je crois que le contenu est compressé en premier, puis découpé en morceaux. De cette façon, les morceaux sont reçus, puis décompressés pour acquérir le contenu réel. Si c'était l'inverse, vous obtiendrez le flux compressé, puis la décompression nous donnerait des morceaux. Ce qui n'a pas de sens.
Une réponse de flux compressé typique peut avoir ces en-têtes:
Content-Type: text/html
Content-Encoding: gzip
Transfer-Encoding: chunked
sémantiquement l'utilisation de Content-Encoding indique un « bout à bout » schéma de codage, ce qui signifie que le client final ou serveur finale est censé décoder le contenu. Les proxies au milieu ne sont pas censés décoder le contenu.
Si vous souhaitez autoriser les proxys au milieu à décoder le contenu, l'en-tête correct à utiliser est en fait l'en-tête Transfer-Encoding. Si la requête HTTP possédait un en-tête TE: gzip chunked, il est alors possible de répondre avec Transfer-Encoding: gzip chunked.
Cependant, cela est très rarement pris en charge. Donc, vous devriez seulement utiliser Content-Encoding pour votre compression dès maintenant.
Chunked vs Store & Forward
Est-ce un étant donné que votre contenu est statique et sa longueur est connue a priori? Sinon, le partage serait beaucoup plus rapide pour les fichiers volumineux. –