Résumé

  • HTTP/2 a rendu avantageuse la réutilisation d’une connexion persistante et multiplexée pour plusieurs autorités d’URI lorsque la résolution et le certificat apportaient des preuves suffisantes. Ces preuves autorisaient une tentative ; elles ne décrivaient pas toute la topologie de service choisie lors de la première négociation.
  • 421 Misdirected Request refuse l’association entre une origine et une connexion. Il ne dit ni que l’URI a déménagé, ni que la requête est mal formée, ni que TLS a nécessairement échoué. Le client peut reprendre la même opération sur une autre connexion, y compris pour une méthode non idempotente ; un simple proxy ne peut pas inventer ce verdict.
  • RFC 8336 a ensuite donné aux serveurs HTTP/2 un moyen d’annoncer à l’avance l’Origin Set d’une connexion. Un client compatible en retire l’origine après un 421. HTTP/3 a conservé ce statut sur QUIC : le problème durable porte sur l’autorité au sein d’un transport partagé, non sur TCP lui-même.

Une entrée commune ne faisait pas un accueil commun

Deux services peuvent présenter le même certificat, résoudre vers la même adresse et être exploités derrière le même équipement frontal. Vu du client, ils paraissent réunis. La première connexion est ouverte, chiffrée et disponible ; le deuxième service porte un nom déjà couvert par l’identité cryptographique du pair. La réutiliser est une économie rationnelle.

Mais l’entrée visible n’est pas nécessairement le plan intérieur. Le SNI envoyé au moment de la négociation peut avoir sélectionné un locataire, un frontal, une politique de port ou un groupe de serveurs d’origine. La connexion établie au nom du premier service arrive au bon bâtiment sans être branchée sur le bon étage pour le second.

Ce second service peut parfaitement fonctionner lorsqu’une nouvelle connexion est négociée en son nom. Ce qui manque n’est donc ni l’existence de l’origine ni forcément la validité de son certificat. C’est l’aptitude du contexte déjà ouvert à parler pour elle.

Le client avait de bonnes raisons d’essayer. Le serveur avait de meilleures raisons locales de refuser. Il fallait un vocabulaire qui conserve ces deux vérités ; HTTP 421 est devenu ce vocabulaire.

Host avait rendu l’intention explicite

Avant même HTTP/2, l’architecture du Web avait dû séparer l’adresse de transport du nom demandé. Lorsque plusieurs sites se sont mis à partager une adresse IP, la destination TCP ne suffisait plus à identifier l’espace de ressources voulu. HTTP/1.1 a imposé le champ Host. HTTP/2 et HTTP/3 transportent généralement la même information dans le pseudo-champ :authority.

Cette évolution répondait à la question posée par le client : de quelle origine parle cette requête ? Elle ne répondait pas à une autre question, détenue par le destinataire : cette origine est-elle configurée dans le service et le contexte de connexion qui viennent de recevoir la requête ?

La distinction subsiste dans RFC 9110. L’hôte et le port de la cible isolent un espace de noms des autres espaces qu’un serveur peut administrer. Après avoir déterminé l’URI cible, le serveur doit néanmoins décider s’il traite, transmet, redirige ou rejette la requête, et vérifier les exigences liées au schéma comme au contexte de connexion.

Host énonce une intention de routage. Il n’accorde pas à tout processus joignable par la socket le mandat de répondre au nom indiqué.

Le gain d’HTTP/2 a élargi l’inférence

La première spécification HTTP/2, RFC 7540, publiée en mai 2015, a fait des connexions persistantes et du multiplexage une pièce centrale du protocole. Une connexion pouvait être réutilisée pour des requêtes dont les autorités d’URI différaient, dès lors que le serveur d’origine paraissait faire autorité.

Sans TLS, cette décision dépendait notamment du fait que le nouvel hôte se résolve vers la même adresse IP. Pour HTTPS, le certificat présenté devait aussi être valable pour le nouvel hôte selon les contrôles qu’aurait exigés une nouvelle connexion. Plusieurs noms alternatifs, ou un joker applicable, pouvaient ainsi soutenir plusieurs origines sur le même canal.

Ces conditions empêchaient une fusion aveugle. Elles constituaient cependant un test depuis l’extérieur. Le client connaissait la résolution, l’identité du pair et son propre état de connexion ; il ne connaissait pas nécessairement la sélection interne effectuée lors de l’établissement initial.

RFC 7540 décrivait précisément le cas d’un équipement terminant TLS et choisissant un serveur d’origine selon le SNI. Une requête ultérieure pour un autre nom couvert par le certificat pouvait alors atteindre le mauvais contexte, même si le pair demeurait par ailleurs autorisé à servir cette origine. L’optimisation révélait une lacune d’observation, pas une absence générale d’autorité.

421 a nommé la mauvaise association

RFC 7540 a introduit 421 Misdirected Request. Sa définition actuelle se trouve désormais dans RFC 9110, au niveau de la sémantique générale de HTTP.

Le statut signifie que le serveur est incapable ou refuse de produire une réponse faisant autorité pour l’URI cible. La cible peut ne correspondre à aucune origine configurée, ou ne pas convenir au contexte de la connexion qui l’a transportée.

Cette formulation ne condamne pas l’origine. Elle ne ferme pas nécessairement la connexion pour les autres requêtes. Elle ne prétend pas que la ressource a changé d’adresse. Elle invalide une relation : cette origine, sur cette connexion, ne peut pas recevoir ici une réponse faisant autorité.

Un serveur d’origine peut émettre ce jugement. Une passerelle agissant pour l’origine peut également le faire. En revanche, RFC 9110 interdit à un proxy de générer 421. Le signal doit rester attaché à la frontière dont il décrit la configuration, sinon le client ne saurait pas si l’origine refuse le contexte ou si un relais intermédiaire préfère arbitrairement une autre route.

L’intérêt du statut tient donc autant à son émetteur qu’à son numéro.

Le certificat était une preuve bornée

Un certificat valide établit que le pair dispose d’une clé privée liée à des identités acceptées par le client. Il ne garantit pas que chaque identité du certificat utilise le même locataire, le même port, le même routage applicatif ou le même groupe de serveurs sur toute connexion.

Trois propositions doivent rester distinctes. La première est la joignabilité : la connexion atteint un point de terminaison. La deuxième est la couverture d’identité : le pair s’authentifie d’une manière acceptable pour l’origine ciblée. La troisième est l’acceptation du contexte : le déploiement veut et peut répondre pour cette origine sur cette connexion précise.

Les deux premières rendent la réutilisation raisonnable. Elles ne transfèrent pas au client la décision sur la troisième. À l’inverse, le refus du serveur ne rend pas fausses les deux premières.

421 maintient cette granularité. Le certificat reste valable dans son domaine de preuve ; il n’est pas transformé en inventaire total des services. La connexion reste exploitable là où son contexte convient ; elle n’est pas transformée en mandat universel.

La reprise changeait de canal, pas de sens

Le mécanisme de récupération est précis. Après un 421, un client peut renvoyer la requête sur une autre connexion — une connexion neuve propre à l’origine, par exemple, ou un service alternatif approprié — que la méthode soit idempotente ou non.

Cette permission exceptionnelle ne rend pas toute répétition d’une écriture sûre après une erreur réseau. Elle découle du sens étroit de 421 : le répondant a refusé de produire la réponse faisant autorité dans ce contexte. Une autre connexion corrige le chemin de remise ; elle ne choisit pas une autre ressource ni une autre opération.

Le mot normatif reste une faculté. Le client peut s’abstenir parce que le corps ne peut pas être reproduit, qu’un secret est lié au canal, qu’une politique locale interdit la reprise ou qu’une opération irréversible exige une confirmation humaine. Le protocole fournit une base de décision, non une garantie commerciale.

Une reprise utile doit surtout modifier une condition. Renvoyer indéfiniment sur la connexion déjà refusée ne constitue pas une récupération. Même si la nouvelle connexion atteint finalement la même adresse et voit le même certificat, son SNI peut sélectionner l’origine correcte et ouvrir un contexte de service différent.

L’URI et l’intention demeurent ; le canal est réévalué.

Un 421 n’était pas une redirection discrète

Une redirection propose une autre cible et s’accompagne normalement d’un emplacement. Elle peut modifier l’autorité, le chemin, les clés de cache et la portée des justificatifs. 421 ne propose aucune nouvelle URI.

Le traiter comme une redirection ferait perdre la propriété la plus importante du signal : le problème concerne le contexte d’acheminement, pas l’identité de la ressource demandée. Un opérateur pourrait masquer une divergence interne en déplaçant le client vers un nom technique ; un client pourrait envoyer des justificatifs à une autorité que le statut n’a jamais désignée.

421 n’est pas non plus 400 Bad Request, car le message peut être parfaitement formé. Ce n’est pas 403 Forbidden, dont le centre de gravité est l’autorisation du demandeur. Ce n’est pas une alerte TLS, puisque la négociation et le certificat peuvent avoir réussi.

Un code étroit évite qu’un défaut d’un niveau redéfinisse le sens des autres niveaux.

ORIGIN a permis d’avertir avant l’essai

La correction réactive ajoute de la latence : il faut envoyer la requête, recevoir 421 et recommencer ailleurs. RFC 8336, publiée en mars 2018, a introduit la trame HTTP/2 ORIGIN afin qu’un serveur puisse annoncer les origines utilisables sur une connexion.

L’extension définit l’Origin Set propre à cette connexion. Une fois l’ensemble initialisé, un client compatible ne doit pas considérer la connexion comme faisant autorité pour une origine absente. Les entrées sont explicites ; les noms génériques avec joker ne sont pas admis. La largeur d’un certificat ne devient donc pas automatiquement la largeur de l’annonce opérationnelle.

La trame décrit une propriété du lien et se traite saut par saut. Un intermédiaire ne la retransmet pas, et un client configuré avec un proxy ignore celle qu’il reçoit de ce proxy. Le serveur peut ajouter des origines par la suite, mais la présence dans l’ensemble ne dispense jamais de valider le certificat.

Surtout, un client compatible qui reçoit 421 retire l’origine concernée de l’Origin Set de cette connexion. Le refus devient une mise à jour de connaissance : ne plus tenter cette origine ici. Il ne devient pas une condamnation globale de l’origine.

Le bon périmètre de mémoire associe donc origine et connexion. Une interdiction globale apprendrait trop ; l’oubli immédiat répéterait la même erreur.

Alt-Svc ne pouvait pas se porter garant de lui-même

Alt-Svc permet à une origine d’annoncer un autre hôte, port ou protocole comme service équivalent. Après un 421, cette voie peut constituer l’autre connexion choisie par le client. Elle ne supprime pas pour autant les contrôles d’autorité.

RFC 8336 précise qu’une annonce de service alternatif ne modifie pas l’Origin Set. Le certificat, la résolution, Alt-Svc et ORIGIN apportent chacun une pièce différente : identité acceptable, possibilité d’atteindre un point, nomination d’une alternative, ou intention d’utiliser une connexion pour certaines origines.

Si l’une de ces pièces suffisait à prouver toutes les autres, l’autorité deviendrait circulaire. 421 conserve au déploiement receveur le droit de dire que la combinaison finale ne convient pas.

Les signaux peuvent coopérer justement parce qu’aucun ne prétend gouverner le système entier.

HTTP/3 a remplacé TCP sans remplacer le problème

La spécification actuelle HTTP/2, RFC 9113, a remplacé RFC 7540 tout en conservant la réutilisation inter-origines et 421. RFC 9114 a transporté HTTP sur QUIC et a, elle aussi, gardé le statut.

Une connexion HTTP/3 est persistante et peut servir plusieurs autorités d’URI. Avant de la réutiliser pour une nouvelle origine, le client doit vérifier que le certificat convient à cette origine. Si ce contrôle échoue, la réutilisation est interdite. S’il réussit, le serveur peut encore refuser que cette connexion serve une origine particulière et répondre 421.

Cette continuité montre la nature historique du mécanisme. Né dans HTTP/2, il a été déplacé dans la sémantique commune puis repris par HTTP/3. La difficulté n’était pas un effet secondaire de TCP. Elle naît dès qu’un canal efficace peut vraisemblablement desservir plusieurs autorités alors que le destinataire possède un contexte de service invisible à l’expéditeur.

Changer le transport n’abolit pas la question : qui peut parler pour quel nom, sur quel canal ?

Mesurer l’arête refusée

Un total de réponses 421 ne suffit pas à diagnostiquer le système. Il faut rattacher chaque événement à la relation qui a échoué : schéma, hôte et port de la cible ; méthode ; identifiants de connexion et de flux ; version HTTP ; adresse distante ; SNI ; ALPN ; identités du certificat ; résultat DNS ayant justifié la réutilisation ; provenance Alt-Svc ; Origin Set ; frontal et serveur d’origine sélectionnés ; rôle de l’émetteur ; puis connexion et résultat de la reprise.

La comparaison donne le sens. Si la connexion mutualisée reçoit 421 et qu’une connexion neuve propre à l’origine réussit, la sélection de contexte est l’explication principale. Si les deux échouent, la configuration de l’origine peut être absente plus largement. Si une seule région est touchée, certificats, annonces et serveurs d’origine ont peut-être convergé à des rythmes différents.

Une occurrence isolée peut être le signe d’une bonne défense : le serveur a corrigé une inférence optimiste. La répétition sans convergence est le signal d’alarme.

Le partage restait une option, pas une constitution

La coalescence des connexions a une valeur réelle. Elle réduit le nombre de négociations et l’état nécessaire, et permet à des requêtes indépendantes de progresser ensemble. 421 ne demande pas une connexion par origine et ne transforme pas chaque divergence en incident hostile.

Il rend simplement l’optimisation révocable. Le client agit sur les preuves qu’il détient. Le déploiement receveur conserve la connaissance de ses locataires, de son SNI, de ses ports et de ses serveurs. Lorsqu’ils ne sont pas d’accord, le client peut préserver la requête tout en changeant le contexte testé.

Sans ce refus typé, la première connexion pourrait acquérir une autorité de fait sur chaque nom que son certificat sait reconnaître. Une économie de transport deviendrait une centralisation des décisions de service.

Le registre IANA des codes d’état HTTP inscrit aujourd’hui 421 sous le nom Misdirected Request et renvoie à RFC 9110. Cette inscription stabilise le nom et la référence interopérables ; elle ne mesure ni la fréquence du statut, ni le comportement universel des clients, ni la qualité de configuration d’un déploiement particulier.

La connexion existait. Son mandat pour la seconde origine, lui, n’existait pas. En distinguant les deux, HTTP a permis de partager un canal sans partager toute l’autorité.