Résumé

  • Dès HTTP/1.0, 204 signifiait que la requête était accomplie sans nouvelle information à afficher. L’agent utilisateur devait conserver la vue du document ayant produit la requête.
  • « No Content » ne veut pas dire « sans état » ni « sans métadonnées ». Les en-têtes décrivent la ressource cible et sa représentation sélectionnée après l’action ; après PUT, un ETag peut identifier la nouvelle version enregistrée.
  • Une réponse 204 se termine avec les en-têtes. Elle ne peut contenir ni contenu ni trailers, et HTTP actuel interdit Content-Length. Le vide est une frontière du protocole.

Réussir ne devait pas toujours ouvrir une nouvelle page

Les premières interactions Web associaient volontiers deux événements : l’action se terminait, puis un nouveau document apparaissait. Ce modèle convenait à la consultation et aux soumissions dont le résultat méritait sa propre représentation. Il convenait moins au geste banal d’enregistrer et de poursuivre.

Un éditeur n’a pas besoin que le serveur lui renvoie le document entier pour prouver l’enregistrement. Il n’a pas davantage besoin d’une page de confirmation qui chasse le texte de l’écran. Le résultat utile tient en peu de choses : l’action est accomplie, voici l’identité de la nouvelle version, continuez.

204 a donné un type à ce résultat. Il ne s’agit pas d’un 200 dont le corps aurait disparu par accident, mais d’un succès où l’absence de contenu fait partie du contrat.

Le code sépare donc la modification réussie du remplacement de la représentation affichée.

HTTP/1.0 a placé la continuité chez l’agent utilisateur

Le RFC 1945, publié en mai 1996, décrit une requête accomplie sans information nouvelle à renvoyer. Si le client est un agent utilisateur, il ne devrait pas changer la vue du document ayant provoqué la requête.

Le texte vise notamment les scripts et les actions. Une saisie peut prendre effet sans déplacer le document actif. Des métadonnées peuvent néanmoins figurer dans les en-têtes et s’appliquer à ce document resté à l’écran.

Deux idées sont donc anciennes. L’absence de corps ne réduit pas la certitude de l’accomplissement. Et la vue préservée n’est pas un hasard d’interface : elle appartient au comportement souhaité.

HTTP/1.0 rangeait déjà 204 parmi les réponses qui ne comportent pas de corps.

HTTP/1.1 a fermé exactement la réponse

Le RFC 2068 maintient ce modèle en 1997 et précise que 204 ne contient pas de message-body. La réponse s’achève à la première ligne vide après les en-têtes.

Le RFC 2616 affine en 1999 la portée des métadonnées. Le serveur a accompli la requête, n’a pas besoin de renvoyer d’entité et peut fournir des informations mises à jour associées à la variante demandée. L’agent garde la vue tout en appliquant ces informations.

Les méthodes utilisent 204 du côté de l’action réalisée. Un DELETE exécuté sans représentation explicative peut choisir 204. Une ressource existante modifiée par PUT peut recevoir 200 avec une représentation de résultat, ou 204 sans elle.

Le corps manquant ne repousse donc pas l’opération dans l’incertitude. La frontière de validation a déjà été franchie.

Un 204 n’est pas un 200 de longueur zéro

Un 200 vide et un 204 peuvent transporter zéro octet de contenu. Ils ne racontent pas la même chose.

Un 200 ordinaire est censé porter un contenu, même si son cadrage indique une longueur nulle. Un 204 affirme qu’aucun contenu supplémentaire n’est nécessaire au résultat réussi. Le statut explique l’absence et fixe les hypothèses de cadrage et d’interface.

Le client n’a donc pas à se demander si une représentation attendue a été perdue. Le serveur, de son côté, ne peut prétendre envoyer 204 puis ajouter discrètement un document de statut.

Un zéro peut être une donnée. Un 204 est une décision de contrôle.

Les en-têtes décrivent l’état après l’action

Le RFC 7231 clarifie en 2014 la temporalité : les métadonnées d’un 204 se rapportent à la ressource cible et à sa représentation sélectionnée après l’action demandée.

L’exemple PUT est décisif. Si la réponse 204 contient un ETag, celui-ci identifie la nouvelle représentation de la ressource. L’éditeur peut faire avancer son marqueur de version sans télécharger à nouveau ce qu’il vient d’enregistrer.

Le corps est absent, pas l’identité du résultat. Date, Cache-Control et les autres champs applicables peuvent encore porter des faits. Un client qui jette tous les en-têtes parce que « 204 ne dit rien » perd la preuve utile à son prochain enregistrement conditionnel.

Cette règle évite aussi d’associer automatiquement l’ETag au corps envoyé dans la requête. Il décrit la représentation choisie après le traitement par l’origine.

La vue restait en place, mais pouvait apprendre

Conserver la vue ne signifie pas la figer dans un état périmé. Le serveur suppose que l’agent utilisateur montrera le succès selon sa propre interface et appliquera les métadonnées nouvelles à la représentation active.

L’origine décide si l’action est accomplie et quelles métadonnées postérieures font autorité. L’agent décide comment signaler localement la réussite et si son application exige une nouvelle lecture.

Cette répartition supprime deux transports inutiles : le serveur n’écho pas le document, le client ne navigue pas vers une confirmation. Pourtant, l’ETag peut faire progresser l’état de concurrence.

La surface demeure ; son modèle local n’a pas à vieillir.

205 trace la branche d’interface opposée

HTTP 205 Reset Content partage l’absence de contenu, mais demande à l’agent de réinitialiser la vue qui a causé la requête, afin de préparer une nouvelle saisie.

204 ne demande aucun effacement. Son scénario d’enregistrement conserve le document pour que le travail continue. Le traiter comme 205 peut vider une saisie, déplacer le focus ou supprimer un contexte local sans autorisation du serveur.

Les deux codes montrent que « réponse sans corps » n’est pas une sémantique suffisante. L’absence est commune ; le contrôle de la surface ne l’est pas.

Un composant qui range tous les succès sans contenu dans une seule branche d’interface détruit précisément la distinction créée par HTTP.

202 se situe de l’autre côté de la validation

HTTP 202 Accepted peut lui aussi être concis, mais son temps est différent. Le traitement a été accepté sans être accompli et pourrait finalement ne jamais l’être.

HTTP 204 annonce l’accomplissement. Rejouer l’action sous prétexte que rien n’est arrivé dans le corps peut dupliquer une modification déjà appliquée. À l’inverse, envoyer 204 alors qu’un traitement asynchrone reste en attente ment sur le moment de validation.

Cette différence est essentielle pour les suppressions, paiements, publications et autres effets dont la répétition coûte. La longueur du corps ne prouve pas la fin ; le statut la situe.

Une réponse vide peut être avant ou après le commit. 202 et 204 indiquent le côté.

Les en-têtes constituent toute la réponse

Le RFC 9110 actuel dit qu’un 204 se termine avec la section d’en-têtes et ne peut contenir ni contenu ni trailers. Le serveur ne doit pas envoyer Content-Length.

Cette rigueur protège les connexions persistantes. Des octets inattendus après une réponse qui ne peut en contenir peuvent être interprétés différemment par deux parseurs ou pris pour le début du message suivant.

Un middleware ne doit donc pas ajouter automatiquement JSON, saut de ligne, pied de traçage ou Content-Length: 0. Son comportement doit dépendre du statut.

La sémantique de l’absence est matérialisée par l’endroit exact où la réponse finit.

La mise en cache heuristique reste soumise à la méthode

RFC 7231 disait 204 cacheable par défaut. RFC 9110 parle désormais de réponse « heuristically cacheable », sauf règle de méthode ou contrôle explicite contraire.

Cela ne rend pas automatiquement réutilisables tous les POST, PUT ou DELETE. Le RFC 9111 lie toujours le stockage et la réutilisation à la méthode, à la clé, à la fraîcheur et aux directives.

Ce qui pourrait être conservé est souvent la métadonnée postérieure, non un corps inexistant. La réutiliser dans le mauvais contexte peut associer un ETag à la mauvaise action.

L’origine doit donc émettre des contrôles délibérés et les intermédiaires conserver des clés conscientes de la méthode.

Parfois, aucun contenu est insuffisant

204 ne convient que si le client n’a pas besoin d’une représentation de résultat pour continuer correctement. Une opération peut produire un identifiant, un reçu, un jeton de récupération, une explication de conflit ou une prochaine URI indispensable.

Cacher ce résultat derrière 204 n’est pas du minimalisme ; c’est un contrat applicatif incomplet. HTTP autorise l’absence, il ne rend pas acceptables toutes les omissions.

L’agent peut aussi relire la ressource si son interface a besoin de la forme canonique. Le statut dit que la réponse n’exige pas de navigation, non qu’une lecture ultérieure est interdite.

Le transport minimal ne fonctionne que lorsque les octets manquants sont réellement redondants.

IANA conserve une absence très précise

Le registre IANA des codes d’état HTTP associe 204 No Content au RFC 9110, section 15.3.5.

L’action a réussi. Aucun contenu supplémentaire n’est envoyé. Les métadonnées parlent de l’après. La vue actuelle ne doit pas être remplacée. Le message s’arrête après ses en-têtes.

Rien de cela ne signifie que la ressource est vide, absente ou supprimée. Rien n’autorise à ignorer les en-têtes. Rien ne commande un reset.

Le nom est bref ; la forme de l’absence est rigoureuse.

L’enregistrement a réussi sans prendre l’écran

204 est un protocole de retenue. L’origine sait que l’action est accomplie, mais ne s’empare pas de la vue suivante avec une page de confirmation. L’agent conserve la responsabilité de son retour local et de la poursuite du travail.

La retenue n’est pourtant pas l’ambiguïté. Le statut fixe l’accomplissement, les en-têtes fixent l’identité et le cadrage fixe la frontière.

Chaque couche garde ainsi son pouvoir : le serveur enregistre, le client reste, la métadonnée avance, le réseau s’arrête.

La page n’a pas changé parce qu’il n’y avait rien de plus à afficher, pas parce qu’il ne s’était rien passé.