Zusammenfassung

  • Schon HTTP/1.0 verstand 204 als erfüllte Anfrage ohne neue anzuzeigende Information. Ein User Agent sollte die Dokumentansicht, aus der die Anfrage kam, nicht wechseln.
  • „No Content“ bedeutet weder „kein Zustand“ noch „keine Metadaten“. Nach heutigem HTTP beziehen sich die Header auf die Zielressource und ihre ausgewählte Darstellung nach der Aktion; bei PUT kann ein ETag die gerade gespeicherte Fassung bezeichnen.
  • Eine 204-Antwort endet mit dem Header-Abschnitt. Sie darf weder Inhalt noch Trailer enthalten, und ein Server darf heute auch kein Content-Length senden. Die Leere ist eine verbindliche Nachrichtengrenze.

Der Save-Knopf stellte zwei getrennte Fragen

Hat der Server die Änderung übernommen? Soll der Browser nun etwas anderes anzeigen? Viele frühe Webabläufe beantworteten beide Fragen mit derselben Bewegung: Nach einer Aktion kam ein neues Dokument. Für eine Suche oder eine Ergebnisliste war das plausibel. Für das Speichern in einem Editor war es unnötig.

Ein Editor braucht nach dem Speichern nicht zwingend eine Kopie seiner eigenen Arbeit. Er braucht Gewissheit über den Commit, möglicherweise eine neue Versionskennung und die Freiheit, an derselben Stelle weiterzuarbeiten. Eine Bestätigungsseite würde die Zustandsänderung mit einem Wechsel der Arbeitsfläche verwechseln.

204 trennte beides. Die Ressource kann sich ändern, obwohl die sichtbare Darstellung nicht ersetzt wird. Der Ursprung bestätigt die Ausführung; der User Agent behält den lokalen Kontext.

Gerade weil die Antwort so wenig transportiert, muss jedes verbleibende Element präzise sein.

HTTP/1.0 machte Kontinuität zur Semantik

Der im Mai 1996 veröffentlichte RFC 1945 beschrieb 204 als erfüllte Anfrage, zu der keine neue Information zurückzusenden ist. Bei einem User Agent sollte sich die Dokumentansicht, die die Anfrage ausgelöst hatte, nicht ändern.

Als Hauptfall nannte der Text Skripte und andere Aktionen, deren Eingabe wirksam werden konnte, ohne das aktive Dokument zu verdrängen. Entity-Header durften dennoch neue Metainformationen tragen, die für das bereits sichtbare Dokument galten.

Damit waren zwei Eigenschaften früh verbunden. Der fehlende Body schwächte die Erfolgsaussage nicht. Und die fortbestehende Ansicht musste nicht mit veraltetem Wissen weiterarbeiten; Metadaten konnten sie aktualisieren.

HTTP/1.0 zählte 204 außerdem zu den Antworten ohne Body. Die Null war keine zufällig leere Darstellung, sondern eine Eigenschaft des Status.

HTTP/1.1 legte das Ende der Nachricht fest

RFC 2068 übernahm das Modell 1997 und formulierte die Framing-Grenze ausdrücklich: Eine 204-Antwort enthält keinen message-body und endet mit der ersten Leerzeile nach den Header-Feldern.

1999 erklärte RFC 2616, der Server habe die Anfrage erfüllt und müsse keinen entity-body zurückgeben. Er könne aber aktualisierte Metainformationen zur angeforderten Variante senden. Der User Agent bleibe in seiner aktuellen Dokumentansicht und wende diese Informationen dort an.

Auch die Methodensemantik zeigte, auf welcher Seite der Ausführungsgrenze 204 lag. Ein vollzogener DELETE ohne Ergebnisdarstellung konnte 204 liefern. Ein bestehendes, durch PUT erfolgreich geändertes Objekt ebenso, wenn keine Darstellung des Ergebnisses gesendet wurde.

Der ausbleibende Body war kein Hinweis auf einen schwebenden Vorgang. Die Operation war bereits über die Commit-Linie gegangen.

Ein 204 ist kein leerer 200

Ein 200 mit Länge null und ein 204 können exakt gleich viele Content-Oktette tragen. Ihre Aussage bleibt verschieden.

200 präsentiert üblicherweise den Inhalt des erfolgreichen Ergebnisses, auch wenn dessen Länge im Einzelfall null ist. 204 erklärt dagegen, dass für diesen Erfolg kein zusätzlicher Response-Inhalt benötigt wird. Der Status gibt der Abwesenheit einen Grund und legt allgemeine Annahmen über Framing und Oberfläche fest.

So muss ein Client nicht rätseln, ob eine erwartete Darstellung versehentlich verloren ging. Umgekehrt darf ein Server nicht 204 ankündigen und anschließend doch ein kleines Statusdokument anhängen.

Null Byte können Daten sein. 204 ist ein Kontrollurteil.

Die Header zeigen auf den Zustand nach der Aktion

Mit RFC 7231 wurde 2014 der Zeitbezug schärfer. Metadaten in einer 204-Antwort beziehen sich auf die Zielressource und ihre ausgewählte Darstellung, nachdem die angeforderte Aktion angewendet wurde.

Das PUT-Beispiel ist besonders folgenreich. Kommt nach einem erfolgreichen PUT ein 204 mit ETag zurück, bezeichnet dieses ETag die neue Darstellung der Zielressource. Der Editor kann seine lokale Versionsmarke aktualisieren, ohne das gerade gespeicherte Dokument erneut herunterzuladen.

Der Body fehlt, nicht aber die Identität des Ergebnisses. Date, Cache-Control und weitere anwendbare Felder behalten ihren Sinn. Wer alle Header verwirft, weil „bei 204 nichts kommt“, verliert gerade den Beleg, den der nächste bedingte Save benötigt.

Das ETag darf auch nicht blind dem Request-Payload zugeschrieben werden. Es bezeichnet den nach der Verarbeitung ausgewählten Serverzustand, der transformiert worden sein kann.

Die Ansicht blieb stehen, ihr Wissen nicht

Eine unveränderte Dokumentansicht ist keine eingefrorene Client-Wahrheit. Die Spezifikation nimmt an, dass der User Agent den Erfolg in seiner eigenen Oberfläche signalisiert und neue oder aktualisierte Metadaten auf die aktive Darstellung anwendet.

Der Ursprung entscheidet, ob die Aktion abgeschlossen ist und welche Metadaten den Zustand danach autoritativ beschreiben. Der User Agent entscheidet, wie Erfolg lokal sichtbar wird, ob Cursor, Formularzustand und Arbeitskontext erhalten bleiben und ob die Anwendung doch noch einen GET benötigt.

Diese Arbeitsteilung hält die gemeinsame Schicht dünn. Das Protokoll fixiert nur, was interoperabel sein muss. Es übernimmt nicht die gesamte Steuerung der Benutzeroberfläche.

Die Seite bleibt dieselbe; das lokale Modell darf trotzdem eine Version weiter sein.

205 bezeichnet die entgegengesetzte Oberfläche

HTTP 205 Reset Content steht im Register direkt neben 204 und hat ebenfalls keinen Response-Inhalt. Für die Benutzeroberfläche trifft er jedoch die gegenteilige Entscheidung: Die Ansicht, aus der die Anfrage kam, soll zurückgesetzt und für eine weitere Eingabe vorbereitet werden.

204 verlangt keinen Reset. Im klassischen Save-Fall bleibt das Dokument bearbeitbar. Behandelt ein Framework alle bodylosen Erfolge gleich, kann es Felder löschen, den Fokus verschieben oder lokalen Kontext verwerfen, obwohl der Server nichts davon angeordnet hat.

„Kein Inhalt“ ist deshalb keine vollständige Kategorie. Der Content-Befund ist gleich, die Kontrolle über die Arbeitsfläche nicht.

Statuscodes verhindern hier, dass eine Transportähnlichkeit zu einer falschen Interaktionsregel wird.

202 liegt vor, 204 hinter der Commit-Grenze

Auch HTTP 202 Accepted kann sehr knapp sein. Seine zeitliche Aussage ist jedoch eine andere: Die Verarbeitung wurde angenommen, ist aber noch nicht abgeschlossen und könnte am Ende sogar ausbleiben.

204 erklärt die Anfrage für erfolgreich erfüllt. Wer allein wegen des fehlenden Bodys erneut sendet, kann eine bereits vollzogene Zahlung, Löschung, Veröffentlichung oder Konfigurationsänderung duplizieren. Wer 204 vor dem Abschluss eines asynchronen Jobs ausgibt, behauptet dagegen einen Commit, den es noch nicht gibt.

Die Unterscheidung betrifft nicht Kosmetik, sondern Wiederholbarkeit und Schadensgrenzen. Die Nachrichtenlänge sagt nichts darüber, ob die Operation noch läuft.

Zwei Antworten können gleich leer wirken und auf entgegengesetzten Seiten des entscheidenden Zeitpunkts liegen.

Hinter den Headern darf nichts mehr kommen

Der heutige RFC 9110 bestimmt, dass 204 mit dem Ende des Header-Abschnitts endet. Die Antwort kann weder Content noch Trailer enthalten; ein Server darf außerdem kein Content-Length senden.

Das schützt vor mehr als bloßer Unordnung. Auf einer persistenten Verbindung können unerwartete Oktette von Empfängern unterschiedlich interpretiert oder der nächsten Nachricht zugeschlagen werden. Aus einem gut gemeinten JSON-Schnipsel, Zeilenumbruch oder Tracing-Trailer wird dann ein Parserkonflikt an der Verbindungsgrenze.

Middleware muss deshalb statusbewusst sein. Selbst ein automatisch angefügtes Content-Length: 0 ist nach aktueller Semantik nicht die korrekte Form eines 204.

Die Header-Leerzeile ist nicht der Anfang eines leeren Dokuments. Sie ist das Ende der ganzen Antwort.

Heuristische Cachebarkeit ersetzt keine Methodenregeln

RFC 7231 nannte 204 standardmäßig cachebar. RFC 9110 spricht genauer von heuristisch cachebar, sofern die Methodendefinition oder ausdrückliche Cache-Kontrollen nichts anderes bestimmen.

Daraus folgt keine pauschale Erlaubnis, beliebige POST-, PUT- oder DELETE-Antworten zu speichern und wiederzuverwenden. RFC 9111 bindet Speicherung und Wiederverwendung weiterhin an Methode, Cache-Key, Frische und Direktiven.

Bei 204 sind es häufig die Metadaten des Zustandswechsels, nicht ein nicht vorhandener Body, die einen Wert besitzen. Ein ETag aus einem falschen Anfragekontext zu übernehmen, kann einer Ressource die Versionskennung einer anderen Aktion geben.

Der Ursprung sollte bei Zustandsänderungen bewusste Cache-Kontrollen senden. Der Vermittler muss die Methode im Urteil erhalten. Weniger Nutzlast bedeutet nicht weniger Kontext.

Manchmal wäre kein Inhalt zu wenig

204 passt nur, wenn der Client ohne Ergebnisdarstellung korrekt fortfahren kann. Manche Geschäftsaktionen erzeugen eine neue Kennung, einen Beleg, ein Recovery-Token, eine Konfliktbeschreibung oder eine URI für den nächsten Schritt.

Solche Informationen hinter einem 204 verschwinden zu lassen, ist kein elegantes Protokolldesign, sondern ein unvollständiger Anwendungskontrakt. HTTP erlaubt, Content wegzulassen; es erklärt nicht jedes Weglassen für sinnvoll.

Benötigt der Editor die vom Ursprung normalisierte Fassung, kann er sie anschließend abrufen. Die Semantik verbietet keinen späteren GET. Sie sagt nur, dass diese Antwort die aktuelle Ansicht nicht durch eine neue Darstellung ersetzt.

Minimaler Transport ist dann richtig, wenn die eingesparten Bytes wirklich redundant sind und nicht der einzige Beleg des Ergebnisses.

IANA registriert eine präzise Abwesenheit

Das IANA-Register der HTTP-Statuscodes verweist für 204 No Content auf Abschnitt 15.3.5 von RFC 9110.

Hinter dem kurzen Namen steht ein enges Bündel: Die Aktion war erfolgreich, weiterer Inhalt fehlt absichtlich, Header beschreiben den Zustand nach der Aktion, die aktuelle Ansicht muss nicht ersetzt werden, und die Nachricht endet nach den Headern.

204 sagt nicht, die Ressource selbst sei leer, nicht vorhanden oder gelöscht. Er entwertet die Header nicht und ordnet keinen Reset an.

Die Abwesenheit besitzt Ursache, Zeitpunkt und eine überprüfbare Grenze.

Der Server speicherte, ohne den Bildschirm zu übernehmen

204 ist ein Protokoll der Zurückhaltung. Der Ursprung darf den Commit bestätigen, ohne aus dieser Gewissheit ein Recht auf die nächste Ansicht abzuleiten. Der User Agent behält die Entscheidung über lokales Feedback und Fortsetzung.

Das entspricht einer schmalen gemeinsamen Spezifikation: Abschluss, Identität und Nachrichtengrenze werden gemeinsam festgelegt; der konkrete Arbeitsablauf bleibt beim Endpunkt, der seinen Kontext kennt.

Zurückhaltung ist dennoch keine Unschärfe. Der Commit muss erfolgt sein, die Metadaten müssen stimmen, und nach dem Header-Ende darf nichts folgen.

Die Seite bleibt stehen, weil nichts Weiteres angezeigt werden muss—nicht weil nichts geschehen wäre.