Résumé

  • Le projet du groupe REGEXT sur les extensions RDAP interdit de recopier machinalement les paramètres d’une requête dans l’URL d’un renvoi. Le serveur d’origine doit connaître la capacité du destinataire et juger que le contenu peut lui être remis.
  • Une extension destinée à fonctionner pendant la recherche d’un serveur faisant autorité ne peut compter sur un paramètre d’URL pour transmettre une information indispensable. Une recherche directe auprès d’un serveur connu peut, elle, utiliser ce mécanisme.

La bonne porte, une commande amputée

RDAP, le protocole d’accès aux données d’enregistrement, permet de demander les fiches de noms de domaine et de ressources Internet comme les adresses IP. Prenons le trajet que décrit le projet : le client cherche le service compétent, un premier serveur lui indique une autre autorité dans l’en-tête HTTP Location, et la requête continue. Ajoutons un paramètre d’extension qui demande une vue particulière. Cette construction montre le choix imposé au premier serveur : la nouvelle adresse peut être juste sans que le paramètre soit transmissible. Il ne suffit pas de déplacer le client ; il faut décider de ce qui franchit la frontière avec lui.

Le mécanisme de découverte de la RFC 9224 part des registres d’allocation de l’IANA. Or, précise le projet REGEXT à la section 4.1, cette carte initiale ne décrit pas les transferts ultérieurs de ressources entre registres régionaux. Pour une ressource passée d’un RIR à un autre, le renvoi sert à quitter l’adresse déduite de l’allocation initiale et à rejoindre l’autorité actuelle. La frontière entre serveurs apparaît dans le trajet normal d’une requête. Le paramètre d’extension, lui, doit encore obtenir son droit de passage.

La RFC 7480 demande aux serveurs d’ignorer les paramètres inconnus. Dans sa section sur les renvois, le projet d’extensions ajoute une règle pour le serveur qui émet la nouvelle URL : ne pas recopier les paramètres à l’aveugle. Ils peuvent contenir des identifiants de sécurité ou des marqueurs de suivi sans rapport avec le second serveur. Un paramètre ne peut figurer dans l’URL de destination que si le premier serveur sait que le second peut le traiter et qu’il est légitime de lui en remettre le contenu. Comprendre un champ et avoir le droit d’en recevoir la valeur sont deux vérifications différentes.

Une conséquence dérange les fournisseurs qui commercialisent des options RDAP : la réponse ordinaire peut arriver parfaitement, alors que la fonction supplémentaire promise a disparu au renvoi. L’interface qui affiche simplement « requête réussie » masque ce changement. À l’inverse, conserver tous les paramètres pour sauver cette fonction peut transformer un simple changement d’adresse en fuite vers un tiers. La décision ne peut être confiée à une règle de copie générale.

Le champ d’emploi réel des paramètres

Le texte autorise les paramètres lorsque le client connaît déjà le serveur faisant autorité et lui adresse directement sa demande. Il cite la recherche RDAP comme exemple. En revanche, une extension appelée à fonctionner pendant une découverte entre autorités doit pouvoir se passer de ce canal : le paramètre peut être supprimé au renvoi. C’est à l’auteur de l’extension de loger l’information essentielle dans un mécanisme compatible avec le trajet qu’il promet aux utilisateurs.

Faire reconstruire la requête par le client paraît séduisant. Le projet relève des obstacles précis : certains clients de navigateur n’accèdent pas au contenu RDAP livré avec un renvoi ; les autres doivent gérer les boucles, les collisions de paramètres et l’encodage de la nouvelle URL. Une fonction conçue pour une adresse directe devient alors un chantier à chaque passage de frontière.

La fiche IETF date la révision 17 du 27 octobre 2026. Le document reste un projet actif du groupe REGEXT, avec l’état IESG « I-D Exists ». La règle sur les paramètres figurait déjà dans une version antérieure. Elle décrit aujourd’hui une responsabilité nette, même si le texte peut encore évoluer avant toute publication en RFC.

Aucun incident identifié de fuite ou de perte de paramètre n’apparaît dans ce dossier. Un échange capturé, montrant la requête initiale, l’URL Location, la capacité du second serveur et la règle de remise applicable, permettrait d’établir un constat sur un opérateur précis.

Sources