Transfer-Encoding: |
Encodage de transfert |
HTTP |
Entêtes |
Syntaxe
Transfer-Encoding: compress
|
Transfer-Encoding: deflate
|
Transfer-Encoding: gzip
|
Transfer-Encoding: trailers
|
Transfer-Encoding: identity
|
Paramètres
Nom |
Description |
compress |
Ce paramètre permet d'indiquer un format utilisant l'algorithme LZW (Lempel-Ziv-Welch) accepté comme nom de codage de transfert. |
deflate |
Ce paramètre permet d'indiquer l'utilisation de la structure zlib acceptée comme nom de codage de transfert. |
gzip |
Ce paramètre permet d'indiquer un format utilisant le codage LZ77 (Lempel-Ziv 1977), avec un CRC de 32 bits accepté comme nom de codage de transfert. |
identity |
Ce paramètre permet d'indiquer la fonction d'identité (c'est-à-dire pas de compression ni de modification). Ce jeton, sauf indication contraire explicite, est toujours considéré comme acceptable. |
trailers |
Ce paramètre permet d'indiquer que le client est prêt à accepter les champs de fin dans un codage de transfert par blocs. |
Description
Ce champ d'entête permet d'indiquer le format de codage utilisée pour transférer en toute sécurité le corps de la charge utile à l'utilisateur.
Remarques
- Le champ d'entête Transfer-Encoding: répertorie les noms de codage de transfert correspondant à la séquence de codages de transfert ayant été (ou seront) appliqués au corps
de la charge utile afin de former le corps du message.
- Le champ d'entête Transfer-Encoding: est analogue au champ Content-Transfer-Encoding du MIME, ayant été conçu pour permettre le transport sécurisé de données binaires
sur un service de transport à 7 bits. Cependant, le transport sécurisé a un objectif différent pour un protocole de transfert propre à 8 bits. Dans le cas de HTTP, le codage de transfert
est principalement destiné à délimiter avec précision une charge utile générée dynamiquement et à distinguer les codages de charge utile n'étant appliqués que pour l'efficacité ou la sécurité du
transport de ceux étant les caractéristiques de la ressource sélectionnée.
- Un destinataire doit être capable d'analyser le codage de transfert par blocs car il joue un rôle crucial dans le cadrage des messages lorsque la taille du corps de la charge utile n'est
pas connue à l'avance. Un expéditeur ne doit pas appliquer plusieurs fois des fragments à un corps de message (c'est-à-dire que la segmentation d'un message déjà fragmenté n'est pas autorisée).
Si un codage de transfert autre que fragmenté est appliqué à un corps de charge utile de requête, l'expéditeur doit appliquer le codage de transfert final comme codage de transfert final pour
garantir que le message est correctement encadré. Si un codage de transfert autre que fragmenté est appliqué à un corps de charge utile de réponse, l'expéditeur doit soit appliquer le codage de
transfert final comme codage de transfert final, soit mettre fin au message en fermant la connexion.
- Contrairement au champ d'entête Content-Encoding:, le codage de transfert est une propriété du message, pas de la représentation, et tout
destinataire le long de la chaîne de requête et de réponse peut décoder le ou les codages de transfert reçus ou appliquer le ou les codage(s) de transfert supplémentaire(s) vers le corps
du message, en supposant que des modifications correspondantes sont apportées à la valeur de champ Transfer-Encoding:. Des informations supplémentaires sur les paramètres de codage
peuvent être fournies par d'autres champs d'entête non définis par cette spécification.
- Le codage de transfert peut être envoyé dans une réponse à une requête HEAD ou dans une réponse 304 Not Modified à une requête GET, ne comprenant
ni corps de message, pour indiquer que le serveur d'origine ont appliqué un codage de transfert au corps du message si la requête avait été un GET inconditionnel.
Cette indication n'est cependant pas requise, car tout destinataire de la chaîne de réponse (y compris le serveur d'origine) peut supprimer les codages de transfert lorsqu'ils ne sont pas
nécessaires.
- Un serveur ne doit pas envoyer de champ d'entête Transfer-Encoding: dans une réponse avec un code d'état de 1xx Informational ou 204 No Content. Un serveur
ne doit pas envoyer de champ d'entête de Transfer-Encoding: dans une réponse 2xx Successful à une requête CONNECT.
- Le champ d'entête Transfer-Encoding: a été ajouté dans le HTTP/1.1. Il est généralement admis que les mise en oeuvre faisant uniquement la publicité de la prise en
charge HTTP/1.0 ne comprendront pas comment traiter une charge utile de transfer-encoded. Un client ne doit pas envoyer de requête contenant Transfer-Encoding: sauf
s'il sait que le serveur gérera les requêtes HTTP/1.1 (ou ultérieures); ces connaissances peuvent prendre la forme d'une configuration utilisateur spécifique ou se souvenir de la
version d'une réponse reçue précédemment. Un serveur ne doit pas envoyer de réponse contenant Transfer-Encoding: sauf si la demande correspondante indique le HTTP/1.1 (ou
version ultérieure).
- Un serveur recevant un message de requête avec un codage de transfert qu'il ne comprend pas devrait répondre par 501 Not Implemented.
Dernière mise à jour : Vendredi, le 10 janvier 2020