Summary

  • Pour RFC 9931, la fin d’une requête Upgrade ou CONNECT n’est pas encore la confirmation du changement de protocole. Un succès récent renseigne une probabilité ; seul le 101 ou le 2xx de la requête en cours fixe l’état de la connexion.
  • Si un client HTTP reconnu libère avant cette réponse des octets choisis par un tiers non fiable, un refus peut les livrer à l’analyseur HTTP/1.1 comme une nouvelle requête. Il faut donc tracer la frontière de libération — sans conserver le contenu — plutôt que transformer une habitude de succès en permission implicite.

Ce que gagne une anticipation, et ce qu’elle risque

L’envoi optimiste vise une économie précise : éviter un aller-retour. Le client suppose que le serveur acceptera de changer l’usage d’une connexion et transmet déjà ce que le nouveau protocole devra consommer. Quand la supposition est juste, le chemin est plus rapide. Quand elle est fausse, il ne suffit pas de dire que quelques paquets ont été envoyés trop tôt. Le destinataire peut attribuer à ces octets une syntaxe et un auteur différents de ceux qu’imaginait l’émetteur.

Publié en mars 2026 dans la filière normative de l’IETF, RFC 9931 traite cette difficulté pour les transitions sur HTTP/1.1. Il met à jour RFC 9112 et RFC 9298. Sa contribution n’est pas une interdiction générale de l’optimisation. Elle précise le moment où une attente devient un fait de protocole.

Avec Upgrade, le client propose un autre protocole d’application sur la connexion existante. Le serveur accepte par une réponse 101 Switching Protocols, qui indique le protocole en vigueur après cette réponse. Avec CONNECT, un 2xx réussi fait passer la connexion en mode tunnel à la fin des en-têtes de réponse. Toute autre réponse signifie que le tunnel n’est pas formé.

Le client doit bien avoir terminé sa requête avant d’émettre selon le nouveau protocole. Mais RFC 9931 insiste : cette condition est nécessaire, pas suffisante. Un serveur peut ignorer le jeton, demander une authentification, refuser une destination, ne pas pouvoir la résoudre ou choisir de rester en HTTP/1.1. Tant que sa réponse n’est pas reçue, le changement n’est qu’anticipé.

L’archive des succès n’est pas l’état de cette connexion

Un système d’exploitation réel a de bonnes raisons d’apprendre du passé. Une transition acceptée il y a une seconde, un taux de refus minime ou une documentation de compatibilité peuvent guider le choix d’un parc pilote. Ils peuvent aussi aider à chiffrer le coût de la prudence. Le problème commence quand une mesure statistique se substitue au verdict individualisé qu’elle cherche seulement à prévoir.

La requête suivante peut atteindre un autre processus, une autre route ou une politique actualisée. Le certificat du client peut être expiré ; la cible peut être indisponible ; un intermédiaire peut être apparu ; le serveur peut réclamer un nouveau défi d’authentification. Même sans aucun changement visible, le protocole laisse au serveur la décision pour la requête présente. Un million de réponses positives ne fabriquent pas la million-et-unième.

Cette séparation rejoint la discipline de preuve défendue par Heng Lu : la règle commune doit rester étroite, et les décisions locales doivent demeurer attribuables. Ici, la règle commune décrit la réponse qui change l’interprétation de la connexion. La politique locale peut choisir une latence, un tampon ou une exception. Elle ne devrait pas maquiller son choix en propriété automatique du protocole.

Il faut donc garder deux colonnes. Dans la première : l’indice prédictif — version, historique, documentation, résultat d’un test. Dans la seconde : l’événement confirmant — réponse actuelle, version HTTP, connexion et protocole retenu. Les deux données peuvent converger presque toujours. Elles ne répondent pas à la même question.

Trois acteurs peuvent habiter les mêmes octets

RFC 9931 ne présente pas comme dangereuse toute conversation à deux. Si chacun des deux participants s’attend déjà à recevoir de l’autre des octets arbitraires, une erreur de prévision peut rester un échec de protocole. La situation change lorsqu’un tiers choisit les données que le client HTTP transmet à un serveur qui, lui, fait confiance à ce client.

Prenons un service local qui demande à un mandataire authentifié d’ouvrir un tunnel TCP. Il fournit aussitôt les premiers octets destinés au service distant. Le mandataire les transmet avant la réponse CONNECT. Or la destination est injoignable. Le serveur refuse le tunnel et poursuit l’analyse HTTP/1.1 de la même connexion.

Si les octets ont été composés pour ressembler à une requête HTTP, le serveur peut les recevoir comme une action du client authentifié. L’application non fiable vient alors d’utiliser l’identité de la connexion pour parler au mandataire. RFC 9112 rattache ce mécanisme à la contrebande de requêtes : des interprétations différentes permettent de cacher une requête qu’une politique aurait autrement bloquée.

Trois erreurs se superposent. La transition prévue n’a pas eu lieu. L’analyseur actif n’est pas celui que le client supposait. Enfin, l’auteur institutionnel de la requête est faux : les octets du tiers héritent de la confiance accordée au client. Un indicateur limité au nombre de transitions refusées ne mesure que la première erreur.

Le risque vaut aussi pour des séquences qui ne forment pas une requête complète. Un analyseur conçu en supposant que son entrée vient d’un pair maîtrisé reçoit désormais un matériau contrôlé par l’adversaire. Cela ne prouve pas une exploitation. Cela montre pourquoi le lieu et l’instant de la libération sont une frontière de sécurité, et pas un détail de performance.

WebSocket, UDP, IP : des réponses différentes à la même ambiguïté

Les normes n’imposent pas un modèle unique d’optimisme. WebSocket avait déjà choisi l’attente : après le message d’ouverture, le client doit recevoir et valider la réponse avant d’envoyer d’autres données. Le masquage à forte entropie des trames client-vers-serveur ajoute une protection de conception distincte.

RFC 9298 autorisait l’envoi anticipé de paquets UDP sous certaines conditions. RFC 9931 modifie cette latitude : elle reste possible avec HTTP/2 ou une version ultérieure, mais elle est interdite avec HTTP/1.x. RFC 9484 applique la même séparation aux paquets IP. Un intermédiaire qui transforme une requête HTTP/2 ou HTTP/3 en HTTP/1.1 doit conserver les capsules jusqu’à l’analyse d’une réponse positive.

La raison tient à la structure. En HTTP/1.1, les requêtes sont séquentielles et leur séparation sur la connexion reste implicite. HTTP/2 et HTTP/3 les associent à des flux explicites. Ainsi, les données d’une transition refusée ne tombent pas simplement dans l’emplacement syntaxique de la requête HTTP/1.1 suivante. Il serait excessif d’en conclure que les versions récentes éliminent tout risque : elles écartent cette ambiguïté précise.

Pour les futurs jetons Upgrade, RFC 9931 évoque trois familles de solution : interdire l’envoi anticipé, imposer un préambule fixe qui fait échouer sans ambiguïté l’analyse HTTP/1.1, ou appliquer un masquage aléatoire. Lorsque la méthode HTTP ne conserve aucun sens après le changement, limiter la demande à GET sans contenu réduit aussi le matériau susceptible de recevoir deux interprétations.

Le registre IANA remplit encore une autre fonction. Il relie un nom de jeton à sa référence normative. L’inscription ne dit pas qu’un serveur donné accepte ce jeton à cet instant. Elle établit un vocabulaire partagé, pas un état d’exécution.

La mitigation CONNECT répartit les devoirs

Pour un client mandataire HTTP/1.1 agissant au profit d’un client TCP non fiable, RFC 9931 exige au moins l’un de deux comportements. Le premier consiste à attendre le 2xx avant de transmettre la charge TCP. Le second ajoute Connection: close, afin qu’un refus ne laisse pas la connexion disponible pour interpréter les octets prématurés comme une nouvelle requête. Cumuler les deux reste possible.

Le serveur mandataire qui refuse possède lui aussi un devoir : fermer la connexion sous-jacente sans y traiter de nouvelle requête. Cette défense absorbe les erreurs de clients qui n’ont pas respecté la frontière. Elle peut toutefois augmenter le coût d’une authentification 407, puisqu’une connexion qui aurait pu être réutilisée doit être reconstruite.

Ce coût ouvre une exception. Le serveur peut désactiver la fermeture s’il sait que le client attend le 2xx. Le texte mentionne User-Agent et la documentation du fournisseur comme moyens d’identification. Or RFC 9110 définit User-Agent comme une information sur le produit émetteur et déconseille l’usurpation ; il n’en fait pas une identité cryptographiquement attestée.

Une exception raisonnable doit donc rester révisable. Elle précise la version du produit, la déclaration du fournisseur, le test local, la chaîne d’intermédiaires, le responsable, la date d’expiration et le signal de retour en arrière. « Ce client est conforme » n’est pas une nature permanente. C’est une conclusion datée qui peut devenir fausse lors d’une mise à jour.

Un reçu de confirmation, sans journaliser le trafic

La réponse existe déjà sur le fil. Pourtant, les journaux d’exploitation séparent souvent l’essai de transition, la libération des octets et l’état final. Daniel Kade propose un reçu compact qui les relie pour les chemins où les données d’un tiers sont en jeu.

Le premier bloc identifie l’époque de connexion et la version HTTP. Il indique Upgrade ou CONNECT, le jeton ou le type de tunnel demandé, et une référence protégée à la cible. Il classe la provenance des données — système interne maîtrisé, composant borné ou tiers non fiable — sans en copier le contenu.

Le deuxième bloc décrit la barrière. Quelle version du client et quelle politique décidaient du départ des octets ? Le chemin a-t-il attendu 101 ou 2xx, demandé la fermeture, utilisé un préambule fixe, appliqué un masquage ou bénéficié d’un flux HTTP/2 ou HTTP/3 distinct ? Des données ont-elles franchi la frontière avant la réponse, et selon quelle construction explicitement admise ?

Enfin, le reçu fixe le résultat : classe de réponse, protocole choisi, analyseur ou tunnel effectivement actif, traitement de la connexion après refus et mesure de confinement. Toute exception porte son fondement, son champ, son propriétaire, son échéance et ses causes d’invalidation.

Il n’est pas nécessaire d’y stocker la charge utile, les certificats, les secrets ou les identifiants d’application. Des empreintes et des états structurés suffisent. Le reçu ne figure pas dans RFC 9931 ; c’est un outil de responsabilité locale. Et il ne doit pas surinterpréter un 2xx : celui-ci confirme la formation du tunnel, non la permission de toute activité future à l’intérieur.

Limites de l’enquête

Les sources gelées décrivent des règles et un risque conditionnel. Elles ne démontrent la vulnérabilité d’aucun produit, l’existence d’aucune attaque ni la fréquence d’une mauvaise implémentation. Elles ne permettent pas non plus de choisir universellement entre tampon, fermeture, préambule et version HTTP plus récente.

La latence demeure une contrainte légitime. Fermer une connexion, attendre l’authentification ou retenir des données a un prix. Le bon contrôle ne nie pas ce prix ; il refuse seulement de le payer avec une confusion sur l’auteur et l’analyseur. Une optimisation est gouvernable lorsque son échec reste borné et observable.

La conclusion peut donc rester modeste : l’ancien succès améliore peut-être la prévision. La réponse actuelle, dans l’état actuel de la connexion, est ce qui confirme la transition.

Sources

  1. RFC 9931 : considérations de sécurité pour les transitions optimistes en HTTP/1.1
  2. Fiche RFC Editor de RFC 9931
  3. RFC 9110 : sémantique HTTP
  4. RFC 9112 : HTTP/1.1
  5. RFC 9298 : transport d’UDP dans HTTP
  6. RFC 6455 : protocole WebSocket
  7. RFC 9484 : transport d’IP dans HTTP
  8. RFC 9113 : HTTP/2
  9. RFC 9114 : HTTP/3
  10. Registre IANA des jetons HTTP Upgrade
  11. Heng Lu, « The Policy Mirror »
  12. Heng Lu, « Minimum Initial Specification, Localized Future Decision, Voluntary Adoption »
  13. Heng Lu, « On Why BTW Media Exists, and Why Reality, Not Advocacy, Is the Product »