Résumé

  • Le 9 septembre 2026, HTTPbis a publié la révision 01 de draft-ietf-httpbis-pre-denied. C’est une draft active du groupe de travail, pas un RFC ni l’attribution définitive d’un code.
  • Le texte remplace « Preliminary Request Denied » par Purpose Declined, propose le numéro 419 et vise le refus fondé sur la valeur déclarée dans Sec-Purpose. Fetch ne définit encore que prefetch.
  • Une origine peut produire cette réponse, tout comme une passerelle agissant pour son compte. Un proxy indépendant ne devrait pas le faire : la différence porte sur l’autorité à représenter la politique de l’origine.
  • Le code ne dit pas quelle règle ni quelle délégation ont conduit au refus. Je propose une trace de décision liant finalité, acteur, mandat, version de politique, horodatage, traitement du cache et résultat. Ce n’est pas une exigence de la draft.

La révision change surtout le détenteur de la parole

La modification la plus visible tient en trois caractères : 419. Dans la révision précédente, le numéro restait un 4xx générique et le titre parlait d’une demande « préliminaire » refusée, avec le préchargement et le préchargement spéculatif en ligne de mire. À 08 h 56 UTC le 9 septembre, la nouvelle version a adopté The Purpose Declined HTTP Status Code et une sémantique plus large : le serveur refuse la requête en raison de sa finalité déclarée.

Il serait toutefois prématuré de présenter 419 comme un fait acquis du Web. Le Datatracker classe le document parmi les travaux actifs de HTTPbis, dans le flux IETF, avec le statut visé Proposed Standard et Tommy Pauly comme shepherd. Son état côté IESG reste I-D Exists; aucun Area Director responsable, traitement IESG ou telechat n’est indiqué. Le registre IANA continue d’afficher 419-420 comme non attribués.

La vraie nouveauté institutionnelle apparaît dans une autre phrase. L’origine peut émettre la réponse. Une passerelle — par exemple un CDN ou un reverse proxy — le peut aussi lorsqu’elle agit pour l’origine. En revanche, un proxy indépendant ne devrait pas fabriquer ce signal. La position dans le trajet réseau ne vaut donc pas mandat. Il faut une délégation qui rattache la décision à l’autorité du service.

Cette séparation est essentielle. Un intermédiaire de transit possède les moyens techniques d’arrêter une requête. Cela ne lui donne pas le droit sémantique de présenter son propre choix comme la politique de l’origine. La draft tente ainsi de préserver la différence entre acheminer, appliquer une règle déléguée et gouverner l’accès au service.

Sec-Purpose est une déclaration, non une preuve d’intention

Le standard Fetch définit Sec-Purpose de façon étroite : la requête sert une finalité autre qu’un usage immédiat. Le champ est structuré et, au moment de cette publication, son unique jeton défini est prefetch. Le serveur peut alors adapter la durée de conservation, refuser le préchargement ou comptabiliser différemment la visite.

Le choix d’un nom plus général prépare de futures valeurs sans les créer. Il n’accorde pas davantage de pouvoirs au serveur non plus. Celui-ci pouvait déjà refuser la requête; la réponse proposée rend simplement la catégorie du refus plus lisible pour le client et pour l’exploitation.

Cette lisibilité doit rester à sa juste portée. Sec-Purpose: prefetch atteste ce que le client a déclaré dans la requête. Il ne révèle ni le souhait de la personne, ni son consentement à un chargement en arrière-plan, ni l’identité du composant qui l’a déclenché. Il ne garantit même pas que la déclaration décrit correctement le comportement réel. De même, 419 ne dévoile pas la règle privée : refus permanent, mesure de charge, coût, géographie, défense contre l’abus ou exception propre à un client.

Le couple requête-réponse porte donc deux affirmations limitées. Le client annonce une finalité; un acteur autorisé la décline sur cette base. Transformer ce dialogue en jugement général sur la légitimité du trafic dépasserait les données disponibles.

Une délégation exploitable doit laisser une empreinte

À la périphérie, le composant qui répond n’est souvent pas celui qui possède la politique. Un CDN termine la connexion et applique une logique par locataire. Un reverse proxy protège une application avant que celle-ci ne voie la requête. Cette architecture économise bande passante et calcul, mais elle brouille facilement la responsabilité.

Lors d’un incident, l’opérateur devra distinguer au moins trois situations : décision prise par l’application d’origine, exécution fidèle d’une règle déléguée, ou intervention autonome d’un intermédiaire. Le code 419 ne contient ni l’identité de l’acteur ni la version de la règle. Il ne dit pas non plus si une exception a été évaluée ou si le refus peut être réutilisé.

Il ne serait pas raisonnable de publier toute cette mécanique dans le message HTTP. Certaines informations exposeraient l’état interne du serveur, risque que la draft mentionne elle-même. Il faut plutôt une trace interne minimale, associée à la réponse : jeton Sec-Purpose exact; composant décideur et rôle; origine ou locataire mandant; identifiant et version stables de la politique; instant de décision; résultat; directive de cache; classe de motif communicable sans danger.

Ce relevé n’est ni un journal universel ni une nouvelle condition normative. C’est un moyen de vérifier, après coup, que « pour le compte de » correspondait à une relation réelle. La proximité topologique avec l’origine n’est pas une preuve de délégation.

Ne pas mettre en cache, c’est limiter la portée du pouvoir

La révision 01 demande un contenu de longueur nulle et prévoit que tout contenu reçu soit ignoré. Elle précise aussi que la réponse n’est pas heuristiquement stockable et qu’elle ne devrait pas être mise en cache. Ces choix empêchent une décision contextuelle de devenir une interdiction durable par accident.

RFC 9110 garantit une dégradation compréhensible : un client qui ne connaît pas 419 doit le traiter comme le membre x00 de la classe, donc comme une erreur 4xx générique. RFC 9111 décrit le cadre général du cache. La consigne plus stricte de la draft évite qu’un refus lié à un instant, une charge ou une politique précise soit rejoué après la disparition de sa cause.

Le danger s’accroît à la périphérie. Une réponse stockée peut survivre à une nouvelle version de politique, franchir la frontière d’un locataire ou toucher une requête dont le contexte diffère. Elle semble alors exprimer une décision de l’origine que celle-ci n’a jamais prise. Associer le traitement du cache au mandat et à la version de règle transforme cette dérive en anomalie vérifiable.

La bonne architecture sépare les fonctions : un signal public minimal pour l’interopérabilité, une trace contrôlée pour la responsabilité et une politique locale pour décider ce qui peut être expliqué au demandeur.

Sources