Résumé

  • Là où 404 conserve l’incertitude sur l’existence et la durée d’une absence, 410 autorise l’origine à signaler un retrait intentionnel et probablement durable lorsque cette conclusion repose sur un état qu’elle maîtrise.
  • Le signal aide les outils de maintenance et peut être réutilisé temporairement par les caches ; il ne donne toutefois à l’origine aucun pouvoir d’effacer les archives, les copies ou les liens détenus par d’autres acteurs.

Une erreur ne suffit pas à raconter l’absence

Imaginons un annuaire de liens qui rencontre chaque nuit la même adresse inaccessible. Il peut réessayer, avertir un rédacteur ou supprimer la référence. Mais le nombre d’échecs ne lui apprend pas pourquoi la page manque. Une panne, une migration inachevée, une ressource interdite que le serveur refuse de révéler et une campagne volontairement close produisent la même apparence. Sans déclaration plus précise, l’outil remplace la connaissance par une politique locale d’attente.

Cette réserve figurait déjà au cœur de HTTP/1.0. RFC 1945, publié en mai 1996, répertoriait 404 parmi les codes couramment reconnus, mais pas 410. La définition de 404 ne tranchait pas entre condition temporaire et permanente. Ce n’était pas une lacune accidentelle : le serveur pouvait honnêtement dire qu’il n’avait rien à fournir sans prétendre connaître l’avenir de la ressource.

L’ambiguïté protège contre une fausse certitude. Elle devient cependant coûteuse après une décision de retrait. Chaque système distant doit alors reconstruire seul une intention que l’origine connaît déjà. Les robots continuent de demander, les inventaires conservent des références mortes, et les responsables humains reçoivent des alertes qui ne distinguent pas incident et fin de vie.

En 1997, l’origine reçoit le droit de préciser

La première spécification publiée de HTTP/1.1, RFC 2068, a introduit 410 Gone. Son texte réunissait trois éléments : la ressource n’était plus accessible, aucune adresse de remplacement n’était connue, et la condition devait être considérée comme permanente. Un client capable d’éditer des liens devait retirer la référence après approbation de l’utilisateur. Si le serveur ne savait pas établir la permanence, il devait rester sur 404.

Ce choix créait une échelle de preuve. Avec 404, l’origine ne s’engageait pas sur la durée. Avec 410, elle publiait une conclusion issue de sa propre gouvernance : fin d’une offre limitée, départ d’une personne, suppression éditoriale ou autre état configuré. Le code n’apportait pas cette connaissance ; il lui donnait une forme interopérable.

Le rôle de l’approbation humaine est révélateur. L’origine n’effaçait pas directement un lien distant. Elle envoyait une information à un client qui possédait sa propre liste et conservait le dernier mot. HTTP coordonnait des autorités séparées au lieu de les fusionner.

La norme a renoncé à promettre l’irréversible

RFC 2616 a explicité l’objectif de maintenance : 410 signalait une indisponibilité intentionnelle et le souhait du propriétaire du serveur de voir disparaître les liens distants. Mais le même texte laissait à ce propriétaire le choix de ne pas marquer toutes les ressources disparues et de ne pas conserver la marque pendant une durée déterminée.

Les révisions suivantes ont corrigé la force du mot « permanent ». RFC 7231, puis RFC 9110, parlent d’une condition probablement permanente. Une page peut être rétablie. Une migration peut révéler un successeur. Une décision peut être annulée. Le protocole exprime l’évaluation actuelle de l’origine, pas une interdiction de changer l’avenir.

Cette prudence donne sa valeur à 404. Dans la norme actuelle, 404 peut signifier qu’aucune représentation courante n’a été trouvée, ou que l’origine refuse d’en révéler l’existence. Il ne dit toujours rien sur la durée. Employer 410 revient donc à réduire volontairement l’ensemble des interprétations. Cette réduction n’est crédible que si quelqu’un possède l’état de cycle de vie et accepte d’en répondre.

Le cache amplifie le message, mais pour un temps fini

410 est heuristiquement réutilisable par un cache. Le mécanisme général de RFC 9111 permet au cache de calculer une durée de fraîcheur lorsqu’aucune expiration explicite n’est fournie. Tant que la réponse reste fraîche, l’intermédiaire peut la servir sans interroger de nouveau l’origine.

La déclaration devient ainsi un état distribué. Elle évite des requêtes répétitives et stabilise le travail des outils de maintenance. Elle augmente aussi le coût d’une erreur : après la restauration d’une page, certains chemins peuvent encore livrer le 410 jusqu’à expiration ou purge de leur copie. Définir le code sans définir la durée, l’observation et la procédure de retour revient à publier une décision sans organiser sa révocation.

Une fraîcheur heuristique n’est pourtant ni une conservation infinie ni une preuve de destruction. Elle décrit combien de temps une réponse peut être réutilisée sans validation. Elle ne dit rien des fichiers internes, des sauvegardes ou des copies détenues ailleurs.

Le serveur contrôle l’accès présent, pas la mémoire commune

Le souhait de voir retirer des liens reste un souhait adressé à des acteurs indépendants. Un éditeur distant décide de sa citation. Un moteur décide de son index. Une archive décide de ses captures. Un cache applique ses règles de fraîcheur. L’origine possède sa réponse, non l’ensemble du graphe hypertexte.

Cette limite empêche 410 de devenir une fiction d’effacement universel. Le code ne dit pas que la ressource n’a jamais existé. Il n’authentifie pas l’opérateur et ne prouve pas son droit juridique à supprimer un témoignage. Il ne commande pas la disparition des versions historiques. Un service d’accès au passé peut conserver un état ancien alors que l’origine courante répond Gone : les deux systèmes rendent compte de temps et d’autorités différents.

410 n’est ni une adresse de remplacement ni la preuve d’une autorité juridique sur les copies détenues ailleurs. Lorsqu’un successeur légitime apparaît ou qu’une obligation distincte explique l’indisponibilité, l’opérateur doit réexaminer le mécanisme et la justification appropriés. La précision d’un code réside autant dans ce qu’il refuse de revendiquer que dans ce qu’il annonce.

Gouverner une conclusion négative

Une organisation devrait donc demander qui est autorisé à conclure qu’une ressource est probablement retirée, sur quelle preuve, avec quelle durée de cache et quel plan de correction. Elle devrait vérifier les successeurs possibles avant de choisir Gone, inventorier les liens importants, conserver la raison de la décision et tester le rétablissement.

Le gain est concret : moins de bruit, moins de requêtes inutiles et des graphes de liens mieux entretenus. Le risque l’est aussi. Le serveur peut revenir à 200 dès demain ; il ne peut pas obliger un tiers à reconstruire une référence déjà supprimée. HTTP 410 montre ainsi une règle plus générale du réseau : un message devient utile quand il rend l’autorité visible, et dangereux quand on lui attribue une juridiction qu’il n’a jamais reçue.

Sources et limites

Le registre IANA des codes HTTP répertorie actuellement 410 sous le libellé « Gone » et renvoie à la section 15.5.11 de RFC 9110. Cette analyse s’appuie aussi sur RFC 1945, RFC 2068, RFC 2616, RFC 7231 et RFC 9111. Ces textes établissent la sémantique, non le comportement actuel de chaque robot, navigateur, cache, moteur ou archive.