Résumé

  • draft-ietf-httpbis-pre-denied-01 propose le code 419 lorsqu’un serveur refuse la requête associée en raison de son objectif déclaré dans Sec-Purpose; le même objectif pourra être accepté ou refusé lors d’une requête ultérieure.
  • Une origine et une passerelle agissant en son nom peuvent produire ce statut. Le reçu doit donc nommer le point de décision au lieu de transformer un nombre observé à la périphérie en panne de l’origine.

Le navigateur avait annoncé un préchargement. Le CDN a répondu avant de consulter l’application, estimant que cette représentation spéculative n’améliorerait pas la navigation. Une seconde plus tard, le clic réel a traversé le même chemin et a reçu la page attendue.

Dans un tableau de bord qui ne conserve que le code, la première réponse devient une erreur du serveur et la seconde une guérison inexpliquée. Dans un registre correctement construit, la première est une décision limitée à une requête déclarée spéculative; la seconde est une nouvelle décision sur une navigation ordinaire. Il n’existe aucune contradiction à résoudre.

La révision 01 de The Purpose Declined HTTP Status Code a été publiée le 9 septembre 2026 comme Internet-Draft actif du groupe HTTP de l’IETF, avec une expiration au 13 mars 2027. Elle vise la voie des standards, mais reste un travail en cours. Au moment du gel des sources, le registre IANA n’attribuait pas le code 419. Le texte ne doit donc être présenté ni comme un RFC, ni comme un code définitivement enregistré, ni comme une preuve de déploiement.

Déclarer un objectif ne démontre pas une intention humaine

Le standard Fetch permet à l’agent utilisateur de décrire l’objectif d’une requête par Sec-Purpose. Un préchargement peut être lancé avant que l’utilisateur ne demande effectivement la ressource. Cette information aide le destinataire à évaluer le coût et l’utilité du travail, mais elle ne certifie ni une personne, ni un consentement, ni une future navigation.

Le champ dit quelque chose de la requête telle que l’agent l’a qualifiée. Il ne dit pas pourquoi l’algorithme du navigateur l’a créée, si le visiteur cliquera, ni si une opération commerciale sera autorisée. Même une valeur parfaitement formée reste un attribut de contexte, non un mandat humain.

Cette limite protège les deux côtés. Le serveur peut appliquer une politique différente au trafic spéculatif sans accuser son auteur d’abus. Le client peut apprendre qu’un préchargement a été refusé sans conclure que l’accès normal est interdit. L’identité, l’autorisation et le résultat appartiennent à d’autres preuves.

Le code classe un pouvoir déjà exercé

Le projet n’ajoute aucune capacité de refus. Une origine ou une passerelle pouvait déjà ne pas servir une requête spéculative. Le nouveau statut rendrait la raison présentée plus lisible que 503 ou 403 dans ce contexte.

Ce point est décisif. Un registre de codes décrit la manière de communiquer une décision; il ne donne pas à n’importe quel intermédiaire le droit de la prendre. La passerelle doit agir pour le compte de l’origine. Un mandataire extérieur à cette relation ne devrait pas produire ce statut.

L’équipe d’exploitation doit donc conserver la preuve de délégation et la preuve de génération. L’adresse de terminaison TLS, la configuration de route, les identifiants de requête, les journaux de bord, Via lorsqu’il existe et les diagnostics Proxy-Status peuvent aider. Aucun élément isolé ne reconstitue toute l’autorité. Le code reçu prouve la réponse reçue; il ne prouve pas à lui seul quelle règle interne l’a fabriquée.

Dire «le CDN l’a décidé» peut être exact sans minimiser la décision. Une passerelle mandatée exerce réellement un contrôle. Dire «l’origine était indisponible» ajoute toutefois une conclusion que le reçu ne porte pas. Le contrôle délégué et la santé du calcul d’origine sont deux objets distincts.

Le temps du reçu s’arrête à la requête associée

Le texte précise que l’indication ne vaut que pour la requête associée. Une requête future portant le même objectif peut réussir ou échouer. Cette phrase interdit de convertir l’événement en propriété permanente de la ressource.

Entre deux tentatives, la charge, l’état du cache, la représentation choisie, la règle de périphérie ou le coût anticipé peuvent changer. Une requête ordinaire peut également suivre un chemin différent. Inversement, le fait qu’une navigation réussisse ne garantit pas que le prochain préchargement sera accepté.

Le modèle de données devrait donc enregistrer un événement horodaté, jamais un booléen durable nommé «préchargement autorisé». La politique en vigueur peut être référencée, mais le résultat passé ne doit pas devenir l’autorité de la décision future. Pour cette dernière, il faut une nouvelle réponse.

Cette discipline est aussi économique. Une organisation qui traite chaque refus spéculatif comme une interdiction durable désactive des optimisations là où elles auraient pu redevenir utiles. Celle qui suppose l’acceptation future gaspille du calcul et de la bande passante. Dans les deux cas, la faute vient d’une portée temporelle inventée.

Sortir de 503 sans masquer l’effet utilisateur

RFC 9110 relie 503 à une incapacité temporaire causée, par exemple, par une surcharge ou une maintenance. Utiliser 503 pour dire «je refuse ce préchargement» contamine le signal d’incident. Le projet propose une classe plus précise afin que les opérateurs ne prennent pas une décision de politique pour une défaillance de service.

Pourtant, le simple déplacement du compteur ne suffit pas. Si tous les statuts non satisfaisants restent comptés comme indisponibilité, le gain sémantique disparaît. Si 419 est exclu de toute analyse, une politique trop agressive peut dégrader la latence de navigation sans apparaître dans les revues.

Il faut donc trois mesures. La disponibilité décrit la capacité du service à répondre. Le taux de refus par objectif décrit la conduite du contrôle. Le résultat de navigation décrit l’expérience observée ensuite. Une même trace peut relier les trois, mais aucune ne remplace les deux autres.

Une baisse de 503 après activation ne prouve pas que le service va mieux. Elle peut seulement signifier que des événements ont reçu un nom plus juste. La direction doit demander si l’attribution a progressé et si le résultat lecteur a changé, pas seulement si la courbe rouge a baissé.

Le cache ne doit pas transformer un instant en règle

Le projet indique que ce statut ne serait pas heuristiquement stockable et qu’il ne devrait pas être mis en cache. Le motif est cohérent avec sa portée: réutiliser la réponse ferait gouverner une nouvelle requête par une décision qui ne lui était pas destinée.

RFC 9111 encadre la fraîcheur et la réutilisation. Cache-Status, défini par RFC 9211, peut aider à savoir si une réponse a été transmise, stockée ou servie depuis un cache. Mais ce diagnostic ne prouve pas la raison interne du refus. À l’inverse, le statut 419 ne prouve pas que le cache a pris ou rejoué la décision.

Lorsqu’une série identique apparaît, l’enquête doit d’abord séparer les nouvelles évaluations des réutilisations. Un identifiant de réponse, l’âge, les directives de cache, les traces de chemin et les reçus du point de décision évitent d’attribuer cent événements à une politique qui n’a peut-être été exécutée qu’une fois.

Un corps explicatif ne devient pas le contrat

Les réponses ne sont pas destinées à être présentées à un utilisateur. Elles devraient avoir un contenu de longueur nulle, et tout contenu envoyé devrait être écarté. Cette règle empêche l’automatisation de dépendre d’une page d’erreur arbitraire.

Un modèle générique peut mentionner la capacité, l’authentification ou un délai sans correspondre à la décision réelle. Une passerelle mal configurée peut ajouter un texte hérité. Le statut proposé porte une assertion limitée: refus selon l’objectif déclaré. Toute explication supplémentaire nécessite son propre format et sa propre provenance.

Le texte signale aussi un risque de fuite d’état interne. Si l’émission varie selon la chaleur du cache, une option expérimentale ou une réserve de capacité, un observateur peut sonder ces transitions. La lisibilité pour l’exploitation autorisée ne doit pas devenir une télémétrie gratuite pour tous.

Sources et limites

Le dossier gelé contient la révision 01 en HTML et texte, les pages Datatracker de statut, d’historique et de références, le groupe HTTP, le standard Fetch, RFC 9110 et 9111, les RFC de diagnostic des mandataires et caches, les textes BCP 14 et le registre IANA des codes HTTP.

Ces sources établissent le contenu du projet et l’état du registre à la date de vérification. Elles ne montrent aucune adoption, aucun incident réel, aucune conduite de fournisseur ni aucune garantie que le texte deviendra RFC. La scène du CDN est un cas analytique, pas un rapport de production.

Sources