Résumé

  • Une requête Upgrade ou CONNECT formule un changement possible ; elle ne choisit pas elle-même le parseur qui recevra la suite.
  • Avant un 101 ou un 2xx, des données prématurées peuvent encore être lues comme HTTP/1.1 si la transition est refusée.

Sur une connexion HTTP/1.1, l’illusion est facile. Une requête est complète, le client connaît le protocole qu’il souhaite utiliser et la première donnée de ce protocole est prête. Dans un diagramme de performance, l’étape suivante semble déjà autorisée. Mais le serveur n’a pas encore répondu. Il peut ignorer l’offre Upgrade, réclamer une authentification, rediriger la ressource, refuser une destination CONNECT ou appliquer une politique locale. La vitesse n’efface pas cette branche.

RFC 9931 donne à cette attente une portée exacte. 101 Switching Protocols rend visible l’acceptation d’un Upgrade ; un 2xx rend visible l’acceptation d’un CONNECT. La fin de la requête est nécessaire avant un basculement, mais elle ne suffit pas. Ce que le client possède alors est une proposition correctement envoyée, non une délégation du serveur à interpréter la suite autrement.

Cette distinction importe parce qu’un refus ne ferme pas automatiquement la conversation. Le serveur peut continuer à lire les octets ultérieurs comme HTTP/1.1. Ainsi, la même séquence peut être pensée par le client comme le début d’un nouveau protocole et être reçue comme une autre requête HTTP. Ce n’est pas une querelle de vocabulaire. C’est un désaccord sur la grammaire applicable, donc sur les contrôles, l’identité de la demande et les règles qui la limitent.

RFC 9931 décrit le risque conditionnel lorsque le client transporte du matériel choisi par une tierce partie non digne de confiance. Un proxy peut recevoir un payload qu’une application locale a fourni. Si ce client le transmet avant le 2xx d’un CONNECT finalement refusé, le proxy peut le lire dans la grammaire HTTP/1.1 toujours active. Le RFC parle alors de request smuggling et d’exploitation de parseur. Il ne transforme pas une optimisation en incident constaté, ni une description de mécanisme en accusation contre un opérateur.

La correction apportée à connect-udp est particulièrement nette. L’envoi optimiste de datagrammes UDP est permis seulement avec HTTP/2 ou une version ultérieure ; en HTTP/1.x, il est interdit à cause du risque de request smuggling. Ce n’est ni un certificat pour HTTP/2 ni une preuve de livraison UDP. C’est une limite sur le sens que des octets précoces peuvent prendre dans une génération précise du protocole.

Pour les clients proxy qui agissent pour des clients TCP non fiables, RFC 9931 impose d’attendre le 2xx avant de transmettre le payload, ou d’envoyer Connection: close. Lorsqu’un CONNECT est refusé, le proxy doit fermer la connexion sous-jacente avant de traiter une requête suivante. Ces règles préservent la frontière entre source du payload, décision de transition, authentification de la connexion et action aval. Elles ne prouvent pas qu’une installation les respecte ni qu’une action est autorisée.

La lecture de Heng Lu aide à ne pas ajouter une souveraineté imaginaire à la trace technique. Un journal peut établir « proposition envoyée ». Une réponse peut établir « transition acceptée ». Une observation peut établir « tel parseur a reçu tels octets ». Une politique locale et une preuve d’effet répondent à d’autres questions. Le code en fonctionnement est un témoin important, mais il ne devient pas, par le seul fait qu’il tourne, l’auteur d’une décision dont une autre partie supportera le coût.

Sources