Résumé

  • Daté du 3 septembre 2026, draft-ietf-regext-epp-https-04 est un projet de travail du groupe REGEXT. Ce n’est ni une RFC, ni une approbation de l’IESG, ni une preuve de déploiement.
  • Dès qu’une requête atteint le traitement EPP et qu’une réponse EPP est produite, la couche HTTP renvoie 200 (OK), y compris lorsque la commande est refusée. Les deux codes répondent à deux questions différentes.
  • Si la commande a pu être exécutée mais qu’aucune réponse EPP valide n’arrive, son issue est indéterminée. Les intermédiaires ne doivent pas relancer le POST ; seul le client, qui connaît la sémantique complète et l’identifiant de transaction, peut décider d’une reprise.

Un centre d’exploitation peut afficher 100 % de succès HTTP pendant que le registre refuse 100 % des commandes. Les chiffres ne mentent pas. Ils ne mesurent simplement pas la même chose.

Cette séparation est au cœur de la révision 04 du projet EPP sur HTTPS. EPP est une conversation XML avec état entre un client de provisionnement et un dépôt partagé. RFC 5730 exige l’ordre des commandes, un état de session et une réponse coordonnée. Le nouveau transport ne convertit pas cette conversation en API REST. Il l’enveloppe dans des POST HTTPS afin de réutiliser pare-feu, répartiteurs de charge et outils de supervision web.

La connexion commence par un POST vide vers une URL communiquée hors protocole. Une réponse valide contient le message d’accueil EPP, le type application/epp+xml, la directive no-store, la protection nosniff et un cookie de session. L’authentification EPP <login> ouvre ensuite la véritable session de provisionnement.

Deux plans de résultat

Après la connexion, chaque POST porte une commande EPP et chaque réponse HTTP porte une réponse EPP. Le serveur doit renvoyer HTTP 200 quand la requête a atteint la couche EPP et que celle-ci a formulé une réponse, que le code EPP indique succès ou échec.

Une erreur HTTP signifie autre chose. Un format HTTP invalide, un type de média refusé, une limite de taille, un quota, une surcharge ou une panne de passerelle peuvent empêcher l’obtention d’une réponse EPP. La classe 4xx ou 5xx décrit alors le traitement de l’enveloppe, pas la décision du registre.

Le cas du cookie rend la distinction visible. Si un identifiant de session absent ou invalide parvient tout de même à la couche EPP, la réponse prescrite est l’erreur EPP 2002 à l’intérieur d’une réponse HTTP 200. Un indicateur limité au code HTTP classera donc une faute de session explicite comme réussite.

La bonne preuve comporte au moins le statut HTTP, le code EPP et l’identifiant de transaction client. Le premier situe la requête dans l’infrastructure. Le deuxième exprime la décision applicative. Le troisième permet de rattacher une reprise à la tentative d’origine.

Le silence après exécution

La situation la plus coûteuse n’est pas un refus, mais une réponse perdue. Une commande de transformation peut avoir atteint le registre et modifié l’objet avant qu’une rupture ne supprime le retour. Le client ne reçoit ni succès EPP ni échec EPP. Le projet qualifie correctement cette issue d’indéterminée.

Relancer mécaniquement le POST ne résout pas l’incertitude. HTTP ne définit pas POST comme idempotent. EPP conçoit ses commandes pour qu’elles puissent l’être, mais l’idempotence dépend de la commande concrète et de toutes ses extensions. Un proxy générique ne possède pas cette connaissance.

La révision 04 réserve donc la reprise au client EoH. Celui-ci doit établir que la panne peut être transitoire, que la sémantique du statut HTTP autorise la reprise et que la commande complète est idempotente. Il doit réutiliser la même commande et le même identifiant de transaction. Il ne peut pas laisser passer la commande suivante avant d’avoir reçu une réponse valide ou abandonné la session. Les intermédiaires sous contrôle de l’opérateur doivent désactiver leur reprise automatique.

Ces exigences protègent l’ordre causal. Une seconde tentative portant un nouvel identifiant peut ressembler à une nouvelle instruction. Une commande suivante peut dépendre d’un état qui n’est encore connu par personne. Une passerelle qui « améliore » la disponibilité peut accomplir deux fois une action que seul le client savait interpréter.

La multiplication HTTP ne multiplie pas les droits d’agir

HTTP/2 et HTTP/3 savent exécuter plusieurs échanges en parallèle. Le projet refuse cette possibilité pour une session EPP : une seule requête peut rester sans réponse. Si un intermédiaire crée malgré tout de la concurrence, le serveur doit choisir un comportement déterminé, rejet ou sérialisation.

La même contrainte traverse l’architecture distribuée. Le cookie représente la connexion EPP, même si les messages empruntent plusieurs connexions HTTP. Un répartiteur peut maintenir une affinité avec une instance, ou l’état peut vivre dans un stockage partagé. L’affinité perd les sessions lorsque l’instance tombe, sauf réplication. Le stockage partagé facilite le basculement, mais devient lui-même une frontière de sécurité et de disponibilité.

Pour une même connexion, le traitement doit rester séquentiel et les changements d’état atomiques. La durée de vie du stockage doit coïncider avec celles des sessions HTTP et EPP. Sans cela, la façade HTTPS reste verte tandis que la conversation de registre qu’elle prétend transporter a cessé d’exister.

Le document mentionne un SDK Verisign en développement pour HTTP/1.1 et HTTP/2 ainsi qu’une variante exploitée par Registro.it depuis 2009. Il précise que ces déclarations viennent des contributeurs et n’ont pas été vérifiées par l’IETF. Elles montrent de l’expérimentation, pas une adoption certifiée.

La discipline des couches de réalité de Heng Lu empêche le raccourci : livraison HTTP, réponse EPP, état stocké, publication DNS et observation par le résolveur sont des pièces liées, jamais des synonymes. Sa primauté du code en fonctionnement désigne aussi le bon décideur : celui qui connaît la commande entière, peut bloquer la suivante, conserver l’identifiant et vérifier l’état avant toute répétition.

HTTPS peut moderniser le transport. Il ne réduit pas la réalité à un voyant vert.

Sources