Résumé

  • Dès 1997, 205 Reset Content signifiait que le serveur avait traité la requête et souhaitait que le navigateur remette la vue de saisie à zéro.
  • La réponse ne transporte aucun nouveau contenu ; les textes de 2014 et de 2022 précisent le retour à l'état initial et l'absence de corps.

Imaginez un guichet où le préposé range votre fiche remplie, puis vous rend aussitôt le même formulaire vierge. Il n'a pas déchiré votre demande. Il prépare déjà la suivante. Le Web des années 1990 avait un code pour cette chorégraphie presque comique : 205 Reset Content.

Dans le RFC 2068 de janvier 1997, le serveur a rempli la demande, et l'agent utilisateur doit remettre à zéro la vue du document qui l'a provoquée. L'exemple est un formulaire : on saisit, on envoie, la zone se vide pour une autre saisie. Le statut parle à deux acteurs à la fois. Le serveur clôt une opération ; le client réorganise la surface de travail de la personne.

Ce petit aller-retour est plus précis qu'un simple « succès ». L'information soumise a quitté la page pour le serveur. La vue du navigateur conserve, elle, ses champs, son curseur et sa place dans le travail. 205 demandait de retrouver l'état initial de cette vue. Aucun nouveau document n'était envoyé pour prendre sa place : le RFC interdisait toute entité dans la réponse. Le signal de réussite et la consigne d'interface tenaient dans la ligne de statut.

Le RFC 2616 de juin 1999 a gardé la scène du formulaire vidé après la soumission. À côté, 204 No Content laissait la vue en place. Le voisinage des deux numéros montre que « réponse vide » décrit les octets, tandis que le comportement attendu du poste de saisie dépend du statut. 205 convenait au travail répétitif : une fiche part, une autre commence, sans imposer un nouvel écran entre les deux.

La révision de 2014, RFC 7231, a donné plus de relief au décor. La vue revient à l'état d'origine reçu du serveur. La zone d'entrée peut être un formulaire, un bloc-notes ou une toile de dessin. On y agit, on soumet, on retrouve la place prête pour le prochain acte. Le protocole traitait l'après-soumission comme une étape de la conversation, jusque dans les gestes visibles de l'utilisateur.

Il a aussi fallu préciser comment envoyer une réponse réellement vide. Le serveur ne doit produire aucune charge utile avec 205. Il peut annoncer Content-Length: 0, terminer un corps découpé par un segment de longueur nulle, ou fermer la connexion après les en-têtes. Ces choix de cadrage ont une fonction terre à terre : le destinataire doit reconnaître la fin du message. Sans cette limite nette, le prochain échange arrive sur un bureau encore encombré par le précédent.

Le RFC 9110 de 2022 conserve le code et son programme : requête accomplie, vue remise à son état initial, aucun contenu supplémentaire dans la réponse. La pile de formulaires n'a plus besoin de papier, mais la question reste familière. Après une action réussie, faut-il préserver le poste de travail ou le préparer pour le suivant ? 205 choisit la seconde cadence.

Le serveur garde le résultat de l'opération. Le navigateur rend à la personne un espace neuf. Entre ces deux mouvements, un statut minuscule dirigeait toute une organisation du travail : enregistrer, vider, recommencer. Le protocole avait inventé la phrase préférée de tout guichet débordé : « Au suivant. »