Résumé

  • Selon la RFC 9110, un client peut envoyer Upgrade pour proposer un changement de protocole sur la même connexion, mais le serveur peut l’ignorer et un intermédiaire doit retirer ce champ propre à la connexion avant un transfert ordinaire.
  • La preuve d’une transition achevée commence par une réponse valide 101 Switching Protocols qui choisit une offre du client, puis relie la fin de la requête initiale au premier échange valide du nouveau protocole.

Imaginons un tableau de migration qui voit Upgrade: websocket dans une requête et classe aussitôt la session comme « WebSocket activé ». Entre le client et l’origine, un proxy applique pourtant le champ Connection et retire l’invitation limitée au saut. L’origine ne la reçoit jamais et répond simplement 200 OK en HTTP/1.1. Aucun protocole ne change, mais le tableau compte une migration réussie parce qu’il confond une offre et son résultat.

Ce scénario est hypothétique et ne décrit aucun fournisseur nommé. Il met en évidence une erreur de preuve : une observation faite d’un seul côté ne peut établir une transition qui exige des faits ordonnés des deux côtés d’une frontière.

La RFC 9110 définit Upgrade comme un mécanisme permettant de passer de HTTP/1.1 à un autre protocole sur la même connexion. Le client peut envoyer une liste ordonnée de protocoles pour inviter le serveur à changer, par ordre de préférence. Le serveur peut ignorer cette invitation. Le champ exprime donc une disposition et une préférence, pas une acceptation, un succès de négociation ou une couverture réelle.

L’invitation est propre à la connexion. L’émetteur d’Upgrade doit aussi inscrire upgrade dans Connection. Cette obligation empêche les intermédiaires de transférer aveuglément l’option reçue. Avant de relayer le message, l’intermédiaire retire les champs désignés par Connection. Si un proxy prend en charge le protocole demandé et choisit de le proposer au prochain saut, il peut générer un nouvel Upgrade limité à ce saut et doit inscrire upgrade dans son propre champ Connection. Une capture côté client ne prouve donc pas que l’origine a reçu la même offre. Une capture côté origine ne prouve pas davantage que le client a reçu une réponse inchangée. Un serveur HTTP/1.0 qui reçoit Upgrade doit l’ignorer.

Une acceptation valide est plus exigeante. Le serveur qui change de protocole doit répondre 101 Switching Protocols et inclure un champ Upgrade indiquant le protocole choisi. Il ne doit pas choisir un protocole absent de la liste offerte. Le 101 constitue ainsi une frontière de décision : avant lui, le client propose ; après une réponse valide, les parties conviennent d’interpréter autrement la même connexion.

Mais la ligne 101 ne suffit pas. Le client ne peut commencer le nouveau protocole avant d’avoir entièrement envoyé la requête porteuse de l’invitation. Le serveur ne doit pas changer si la sémantique du message reçu ne peut être respectée par le nouveau protocole. Après le changement, le serveur est censé poursuivre sa réponse à la requête initiale sous une forme équivalente à une réponse HTTP dans le protocole choisi. Il faut donc conserver la frontière de fin de requête et le premier échange correctement formé.

Le mécanisme ne remplace pas le transport sous-jacent et ne crée pas une autre connexion. Seul le protocole applicatif supérieur change sur la connexion existante. Joindre une offre observée sur une connexion à un 101 ou à une trame vue sur une autre fabriquerait une transition étrangère au mécanisme décrit.

Cette analyse est distincte de R067 sur l’exhaustivité de Via, de R064 sur une annonce Alt-Svc, du travail Strategic Local sur la restauration de priorité et de B842 sur la corrélation d’identifiants IPv6 temporaires. Ici, l’événement contrôlé est le changement du protocole applicatif sur une connexion précise.

Un reçu fiable associe la requête exacte, les offres ordonnées, les jetons Connection, les observations avant et après chaque intermédiaire, le statut final, le protocole sélectionné, la fin des octets de requête, le point exact du changement, le premier message valide du nouveau protocole et tout repli ou fermeture. Ce reçu n’est pas un élément de protocole défini par l’IETF, mais une synthèse éditoriale de preuves d’exploitation. « Offre observée » doit rester différent de « changement achevé ».

Sources