Résumé

  • Un projet actif du groupe HTTP propose 419 Purpose Declined lorsqu’un serveur refuse une requête en raison de son Sec-Purpose. C’est le reçu d’une décision pour une requête, non une interdiction durable, un diagnostic de santé ou une nouvelle faculté de refus. Au 29 septembre 2026, l’IANA indiquait toujours 419–420 comme non attribués.
  • Le vrai chantier est la continuité sémantique : usage déclaré, point de décision mandaté, absence de mise en cache, comportement des clients anciens, calcul du SLO et demande réelle ultérieure doivent rester reliés. Sinon, 419 finit dans une case « autre 4xx » et l’erreur d’interprétation demeure.

Le paradoxe apparaît dans le rapport d’incident : aucune saturation, aucune file en dérive, aucun contrôle de santé en échec, mais une hausse brutale du taux d’erreur. Les requêtes concernées ne venaient pas d’un lecteur qui attendait la page. Elles avaient été lancées par anticipation, afin de préparer une ressource susceptible d’être utilisée bientôt.

Une prélecture est un investissement incertain. Le client espère gagner de la latence ; l’origine, le CDN ou les deux supportent le calcul, les accès aux données et le transport. Refuser une partie de ce travail facultatif peut donc être une politique rationnelle. Pourtant, si le refus prend la forme de 503 Service Unavailable, la télémétrie raconte que le serveur n’a pas pu servir une requête valide.

Le projet draft-ietf-httpbis-pre-denied-01, publié le 9 septembre 2026, propose une distinction étroite : 419 Purpose Declined signifie que le serveur refuse cette requête à cause de l’usage qu’elle déclare. Le document est un Internet-Draft du groupe HTTP visant la voie des standards. Ce n’est pas un RFC, et le registre IANA gardait 419–420 non attribués lors du gel des preuves.

La proposition ne crée aucun pouvoir. Un serveur peut déjà refuser. Elle rend seulement visible la surface de contrôle qui a bougé : capacité défaillante ou choix d’admission. Sans cette séparation, une décision locale réussie consomme le budget d’erreur d’un service pourtant disponible.

Une intention déclarée n’est pas une demande certaine

Le standard Fetch définit Sec-Purpose pour une requête poursuivant un objectif autre que l’usage immédiat par l’utilisateur. Le seul jeton défini est aujourd’hui prefetch, c’est-à-dire la récupération d’une ressource que le client anticipe comme bientôt nécessaire. L’algorithme Fetch ajoute Sec-Purpose: prefetch lorsque l’initiateur est une prélecture.

Le serveur peut en tenir compte pour modifier la durée de cache, interdire la prélecture ou ne pas la compter comme une visite. Mais l’en-tête ne prouve ni une navigation future, ni la qualité de la prédiction, ni l’identité, ni un gain pour l’utilisateur. Il décrit le contexte de départ.

Cette limite répartit correctement l’autorité. Le client explique son motif. L’origine, ou une passerelle explicitement mandatée par elle, décide si ce motif mérite du travail maintenant. Un intermédiaire qui voit passer la requête n’acquiert pas ce droit par simple proximité.

La spécification commune peut donc rester minimale : une déclaration fine et un résultat de refus fin. Les seuils de charge, coûts, contrats ou préférences produit restent des choix locaux chez ceux qui en assument les conséquences.

Pourquoi 503 fabrique un faux incident

Dans RFC 9110, la classe 5xx désigne l’échec du serveur à satisfaire une requête apparemment valide. Voir 503 monter doit conduire l’astreinte vers la capacité, la maintenance ou une dépendance. Quand le même code exprime aussi « je ne souhaite pas exécuter cette spéculation », cette déduction légitime devient une fausse alerte.

Les effets dépassent l’astreinte. Le budget d’erreur mélange demande réelle et travail optionnel. Un rapport client présente une indisponibilité inexistante. La planification peut financer de la capacité pour supprimer une courbe produite par une politique volontaire. Un objectif de fiabilité commence alors à récompenser l’acceptation de travail inutile.

403 Forbidden reste trop large : il suggère une interdiction concernant la ressource ou l’action, alors que la même ressource peut être servie immédiatement à un utilisateur, et qu’une prélecture suivante peut être acceptée.

419 apporte une phrase plus exacte : cette requête a été déclinée à cause de son usage déclaré. Il ne dit pas que l’origine est saine, que la politique est juste ou que la ressource restera refusée.

Le refus expire avec la requête

Le projet précise qu’un 419 ne concerne que la requête associée. Une demande future ayant le même usage pourra réussir ou échouer. Cette règle empêche un jugement circonstanciel de devenir l’état durable de la ressource.

Le texte indique aussi que 419 n’est pas heuristiquement cacheable et recommande de ne pas le mettre en cache. Réutiliser hier un refus pris sous une charge et une politique particulières retirerait la décision à l’origine. Le danger maximal serait de servir ce refus mémorisé à une demande immédiate : l’économie facultative deviendrait alors une panne réelle.

La réponse n’est pas destinée à être affichée ; elle devrait avoir un contenu de longueur nulle et tout contenu envoyé devrait être ignoré. Ce n’est pas un nouveau support éditorial d’erreur. L’explication utile se trouve dans le contexte de requête, la version de politique et les traces.

Un test sérieux envoie plusieurs prélectures sous des conditions différentes, puis une demande immédiate. Il vérifie que le cache ne rejoue pas 419, que chaque requête rejoint le bon décideur et qu’aucune réponse vide ne devient une page d’erreur visible.

L’émetteur doit être mandaté

L’origine et les passerelles agissant pour elle, notamment un CDN ou un reverse proxy, peuvent générer 419. Les autres proxies ne devraient pas le faire. Ce point donne au code une frontière d’autorité.

Le reçu doit donc identifier où la décision a été prise, quelle délégation la couvrait, quelle version de règle a été exécutée et quelles entrées ont compté. Sec-Purpose n’authentifie personne. Une connexion protégée peut établir d’autres identités, mais le mot prefetch n’en hérite pas.

La capacité d’un CDN à distribuer des octets ne vaut pas mandat général pour redéfinir l’admission. Sans preuve de délégation, une réponse 419 d’intermédiaire peut masquer que l’origine n’a jamais choisi de refuser.

Le projet avertit aussi d’une fuite possible d’état interne. Si la fréquence des refus révèle charge ou seuil, le code devient un canal d’observation. Il faut régler la granularité et limiter l’exploration, pas revenir à un 503 ambigu.

Les anciens clients gardent la classe, pas nécessairement le sens

RFC 9110 impose qu’un client ne connaissant pas un code précis en comprenne au moins la classe ; un 4xx inconnu est traité comme l’équivalent générique de 400. Cette compatibilité évite de prendre 419 pour un succès. Elle ne préserve pas l’explication.

Un SDK peut normaliser le résultat en « bad request », un entrepôt de logs en « autres 4xx », un outil de retry en erreur de syntaxe et un tableau de bord en rouge. Chacun fonctionne, mais la distinction disparaît.

La primauté du code exécuté exige donc un parcours complet : client, CDN, origine, cache, traceur, pipeline de métriques, alerte, SLO et rapport. La future attribution d’un numéro ne reprogramme aucun de ces composants.

Il faut conserver trois dimensions : la présence de l’usage spéculatif, l’identité du décideur et le résultat de la demande immédiate ultérieure. Beaucoup de 419 peuvent signaler un nouveau comportement client sans incident. À l’inverse, une hausse simultanée des échecs immédiats peut révéler une panne que la nouvelle catégorie ne doit pas excuser.

Relier le reçu au résultat

La chaîne probante enregistre l’identifiant de requête, la méthode, la cible, l’initiateur, Sec-Purpose, la version cliente et l’état de cache ; puis l’identité du décideur, sa délégation, la version de politique et la règle ; enfin le statut, les contrôles de cache, la longueur et la position de trace. Elle rejoint ensuite la demande réelle éventuelle, sa latence, les octets, le travail origine et le résultat visible.

Sans ce raccord, 419 ne mesure ni économie ni dommage. Si aucun utilisateur ne demande la ressource, le refus a peut-être évité du travail, mais il faut encore le quantifier. Si une navigation suit et réussit, la santé du service est démontrée tandis qu’un coût de latence reste possible. Si elle échoue aussi, 419 ne gomme pas l’incident. Si elle reçoit le 419 mis en cache, l’implémentation a violé la portée d’une requête.

Le SLO doit nommer sa population. La disponibilité des demandes immédiates n’est pas le taux d’acceptation des prélectures. On peut observer les deux, puis les corréler aux coûts et à l’expérience, sans les confondre.

Les sources primaires établissent le projet, son état de procédure, la sémantique Fetch, les règles HTTP et l’absence d’attribution IANA. Elles ne prouvent aucun déploiement, navigateur, CDN, économie, adoption ou résultat. Ces affirmations exigent matrices d’implémentation, essais contrôlés, traces et mesures.

La proposition est utile parce qu’elle reste modeste : nommer un refus déjà possible, le limiter à une demande, éviter le cache, ne pas créer de contenu utilisateur et borner ses émetteurs. Le reste appartient aux systèmes réellement exécutés. Un tableau de bord ne pourra dire que le serveur allait bien qu’après avoir relié la déclaration, la décision et la demande réelle.

Sources