07. Délimitation et encodage de transfert

Comprendre le mécanisme

En HTTP/1.1, les règles de délimitation permettent de savoir où se termine un corps sur une connexion. Transfer-Encoding et Content-Length ont des rôles distincts et des combinaisons peuvent être dangereuses. La compression d’une représentation décrite par Content-Encoding est encore une autre notion. Il faut lire la règle normative du protocole utilisé plutôt que compter sur une heuristique maison.

Raisonner et vérifier

Deux parseurs en chaîne doivent refuser ou normaliser de façon compatible les messages ambigus. Une validation seulement dans le contrôleur peut arriver trop tard si l’intermédiaire a déjà découpé la connexion autrement. Maintenez les serveurs et bibliothèques, vérifiez les règles des proxys et mesurez leur comportement sur une chaîne isolée. Documentez également la traduction entre versions HTTP.

Contenu et transfert

Transfer-Encoding et Content-Encoding ont des rôles distincts. Compression du contenu et délimitation du transfert ne se confondent pas. Content-Encoding décrit un codage de représentation tel que gzip. Transfer-Encoding en HTTP/1.1 intervient dans le transfert et sa délimitation ; les deux champs ne répondent pas à la même question.

Parseurs en désaccord

Des parseurs incohérents créent une frontière dangereuse. La désynchronisation exploite précisément des divergences. Si un frontal et un backend ne placent pas la fin du message au même endroit, les octets restants peuvent être interprétés différemment. Le risque se situe dans leur composition, pas seulement dans le contrôleur.

Chaque saut

La délimitation doit être non ambiguë sur chaque saut. Les messages successifs doivent être séparés selon le protocole. Une connexion peut être terminée puis reconstruite par un proxy. Vérifiez la délimitation et les règles de rejet à chaque saut au lieu de supposer qu’un parsing navigateur correct impose celui du backend.

Conversion de version

Une conversion de version demande une politique correcte. La traduction vers un backend peut conserver des risques. Un frontal HTTP/2 peut émettre une requête HTTP/1.1 vers l’origine. Cette traduction doit conserver une délimitation cohérente et retirer ou refuser les champs incompatibles selon le protocole cible.

Longueurs contradictoires

Les champs de longueur contradictoires demandent un traitement strict. Ce n’est pas un mécanisme de choix de taille. Une politique stricte doit éviter les interprétations ambiguës de longueurs et champs de transfert. Appliquez les règles du protocole dans les intermédiaires et vérifiez le refus dans un laboratoire représentatif.

Environnement isolé

Les tests de parseur appartiennent à un laboratoire isolé. Ces essais peuvent perturber des requêtes tierces. Les tests de frontières de messages peuvent perturber des connexions mutualisées. Utilisez une chaîne dédiée avec données factices, sans utilisateurs tiers, et conservez versions et configuration exactes.

Corps par morceaux

Les budgets s’appliquent aussi aux corps transmis par morceaux. Le mode de transfert ne supprime pas les limites de ressources. Un transfert chunked ne rend pas le corps sans limite. Comptez les octets reçus et appliquez temps, taille et ressources pendant lecture, y compris lorsque la taille totale n’est pas annoncée initialement.

Avant le framework

Le framework ne contrôle pas tous les parseurs amont. Les composants et leurs versions doivent être examinés séparément. Une vérification PHP arrive après le parsing de ses prédécesseurs. Maintenez et configurez les composants amont ; le contrôleur ne peut pas réparer rétroactivement une interprétation divergente déjà utilisée.

Réutilisation

Une connexion réutilisée amplifie certains écarts de délimitation. La persistance peut relier plusieurs messages sur le même canal. Sur une connexion persistante, des octets mal attribués peuvent affecter l’échange suivant. Testez la réutilisation dans la chaîne isolée et vérifiez que le refus ferme ou traite correctement l’état du canal.

Traces sûres

Les journaux doivent aider sans enregistrer de secrets. Des traces de laboratoire et métadonnées peuvent suffire. Conservez décisions de parseur, corrélation et tailles nécessaires sans enregistrer cookies ou corps sensibles. Les captures de laboratoire peuvent être détaillées parce que leurs données sont conçues pour être publiques.

Atelier guidé : lire, expliquer et vérifier le code

Content-Encoding: gzip
Transfer-Encoding: chunked

Extrait HTTP/1.1 de laboratoire, pas une politique universelle de proxy.

L’extrait montre simultanément un contenu gzip et un transfert chunked dans un contexte HTTP/1.1. Expliquez les deux couches sans en déduire une politique universelle applicable à HTTP/2. Pour valider la sécurité, il faut examiner la délimitation et les conversions de toute la chaîne réelle.

Ils ne décident pas des permissions. gzip nomme un codage, pas un nombre. Le contenu compressé peut être transporté selon une délimitation séparée. Aucun de ces champs ne signifie TLS.

Travail pratique : Inventoriez les parseurs traversés par votre requête de laboratoire et leurs versions. Recherchez les règles documentées concernant les délimitations ambiguës.

Critères de correction : Comparez configurations et contrats, puis utilisez des tests de non-régression dans un environnement dédié. Vérifiez le refus avant tout traitement métier et la fermeture de la connexion si la politique l’exige.