Ein sauber gesetzter Statuscode entscheidet oft darüber, ob ein Client die Antwort sofort versteht oder unnötig Arbeit macht. Die 204-Antwort, oft als 204 response bezeichnet, ist genau dann sinnvoll, wenn eine Anfrage erfolgreich war, der Server aber bewusst keinen neuen Inhalt zurückgibt. In diesem Text zeige ich, was der Status in der Praxis bedeutet, wann ich ihn auf einem Webserver einsetze, welche Header erlaubt sind und wo die häufigsten Fehler liegen.
Die wichtigsten Punkte auf einen Blick
- 204 bedeutet Erfolg ohne Antwortkörper.
- Der Client bleibt auf seiner aktuellen Ansicht und muss nichts neu rendern.
- Typische Fälle sind DELETE, PUT und PATCH, wenn keine Darstellung zurückkommen soll.
- Content-Length und Transfer-Encoding gehören bei 204 nicht in die Antwort.
- ETag kann trotzdem nützlich sein, weil Metadaten weiterhin übertragen werden dürfen.
- Wenn der Client neue Daten braucht, ist 200 oder 201 meist die bessere Wahl.
Was der 204-Status wirklich bedeutet
RFC 9110 beschreibt den Status als erfolgreiche Verarbeitung ohne zusätzlichen Content; die Antwort endet mit dem Header-Block. Für mich ist das der entscheidende Punkt: 204 sagt nicht nur „es hat geklappt“, sondern auch „du brauchst dafür keinen neuen Body mehr“. MDN formuliert es aus Sicht des Browsers passend: Die aktuelle Ansicht muss dafür nicht verlassen werden.
Genau deshalb ist 204 kein Ersatz für einen stillen 200er. Ein 200er kann einen Body tragen und den Client mit frischen Daten versorgen, 204 dagegen verzichtet bewusst darauf. Der Unterschied wirkt klein, spart aber in APIs und Webanwendungen echten Aufwand, wenn der Client die Rückgabe ohnehin nicht auswerten soll.
Ich sehe 204 vor allem als sehr präzises Signal für erfolgreiche Aktionen mit null zusätzlichem Informationsbedarf. Sobald der Client mehr wissen muss als „erfolgreich“, ist ein anderer Statuscode oft sauberer. Damit ist der Rahmen klar, und jetzt lohnt sich der Blick auf die Situationen, in denen 204 auf einem Webserver wirklich passt.
Wann ich 204 auf einem Webserver einsetze
Am häufigsten taucht 204 nach einer Änderung auf, bei der die aktuelle Oberfläche bestehen bleiben soll. Das ist besonders sinnvoll, wenn der Client bereits alle nötigen Daten kennt und der Server nur bestätigen muss, dass die Operation erfolgreich war.
- DELETE - Eine Ressource wurde entfernt, und es gibt keinen Grund, dem Client danach noch ein leeres Dokument zu schicken.
- PUT - Ein Datensatz wurde vollständig aktualisiert, der Client soll aber auf derselben Bearbeitungsansicht bleiben.
- PATCH - Kleine Teiländerungen, etwa ein gesetztes Häkchen oder ein umgeschalteter Status, brauchen oft keinen neuen Body.
- „Save and continue editing“ - Der klassische Fall in Formularen, Wiki-Editoren oder Admin-Oberflächen: speichern, aber die Eingabemaske behalten.
- API-Schalter - Favorit setzen, Benachrichtigung aktivieren, Freigabe umschalten: Erfolg ja, neue Darstellung oft nein.
Diese Fälle haben etwas gemeinsam: Der Server bestätigt den Zustand, ohne die bestehende Oberfläche umzubauen. Genau das macht 204 im Alltag so effizient, weil weder Bandbreite noch Client-Logik für einen Body verschwendet werden. Entscheidend ist aber, dass die Antwort technisch sauber bleibt, und das führt direkt zu den Header-Regeln.
Welche Header bei 204 erlaubt sind und welche nicht
204 ist streng, aber nicht leer im Sinne von „ohne Bedeutung“. Metadaten dürfen mitkommen, der Body nicht. Das ist der Punkt, an dem viele Implementierungen unnötig stolpern, weil Frameworks gern automatisch Header ergänzen oder eine Standardantwort erzeugen.
| Aspekt | Regel bei 204 | Praktische Bedeutung |
|---|---|---|
| Antwortkörper | Keiner | Der Client soll nichts parsen oder rendern. |
| Content-Length | Nicht senden | Verhindert Konflikte mit der leeren Antwort. |
| Transfer-Encoding | Nicht senden | Die Antwort endet mit dem Header-Block. |
| ETag | Erlaubt und oft nützlich | Hilft beim Abgleich des neuen Zustands nach einem Update. |
| Cache-Control | Erlaubt, aber bewusst setzen | 204 ist standardmäßig cachebar, trotzdem sollte die Cache-Strategie klar sein. |
Ein korrektes Beispiel sieht sehr unspektakulär aus, und genau das ist gewollt:
HTTP/1.1 204 No Content
Date: ...
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"Wenn ein Framework hier automatisch JSON oder eine Länge von null ergänzt, ist das kein kosmetisches Problem, sondern ein semantischer Fehler. Saubere 204-Antworten sind bewusst kurz und technisch eindeutig. Als Nächstes lohnt sich deshalb der Vergleich mit den Statuscodes, die in der Praxis am ehesten verwechselt werden.
Worin 204 sich von 200, 201, 205 und 304 unterscheidet
Im Alltag ist 204 oft deshalb missverstanden, weil er neben ähnlich klingenden Erfolgsantworten steht. Ich entscheide mich deshalb gern über die Frage: Soll der Client nur den Erfolg kennen, oder braucht er danach eine neue Repräsentation, einen Reset der Ansicht oder einen Cache-Hinweis?
| Statuscode | Wofür er steht | Wann ich ihn eher nehme |
|---|---|---|
| 200 OK | Erfolg mit Inhalt | Wenn der Client die aktualisierte Darstellung direkt braucht. |
| 201 Created | Neue Ressource wurde erzeugt | Wenn nach einem POST etwas Neues entstanden ist und der Ort der Ressource relevant ist. |
| 204 No Content | Erfolg ohne Inhalt | Wenn die Aktion erledigt ist und kein Body mehr nötig ist. |
| 205 Reset Content | Erfolg mit Rücksetzen der Ansicht | Wenn die Eingabemaske oder der View bewusst auf Anfang springen soll. |
| 304 Not Modified | Cache bleibt gültig | Wenn ein bedingtes GET oder HEAD bestätigt, dass die vorhandene Kopie reicht. |
Typische Fehler, die aus einer sauberen Antwort ein Problem machen
Die häufigsten Fehler entstehen nicht beim HTTP-Standard, sondern bei der Implementierung im Webserver oder im Framework darum herum. Viele Stacks meinen es gut und liefern automatisch einen Body, eine Content-Length oder ein JSON-Objekt zurück, obwohl 204 gerade keins haben soll.
- Body trotz 204 - Browser und Clients können so eine Antwort ablehnen oder ignorieren.
-
Automatische JSON-Verarbeitung auf dem Client - Wer bei 204 trotzdem
.json()aufruft, produziert unnötige Fehlerpfade. - Falscher Status für asynchrone Arbeit - Wenn die Verarbeitung noch läuft, ist 202 Accepted meist ehrlicher.
- 204 bei echter Neuerstellung - Wenn ein Objekt entstanden ist, ist 201 Created meist die klarere Aussage.
- Fehlende Trennung zwischen UI-Reset und Erfolg - Wer ein Formular bewusst zurücksetzen will, sollte 205 prüfen statt 204 zu erzwingen.
- Automatische Header des Frameworks - Besonders Content-Length und Transfer-Encoding sollten bei 204 nicht „mitlaufen“.
In der Praxis prüfe ich solche Antworten immer im Netzwerk-Tab oder im Roh-HTTP-Log, nicht nur über das Framework-Objekt. Erst dort sieht man, ob der Server wirklich nur den Header-Block sendet und ob der Client die Antwort korrekt behandelt. Das ist der Moment, in dem aus einer theoretisch richtigen Konfiguration ein belastbarer Betrieb wird.
Was ich vor dem Rollout in Produktion prüfe
Bevor ich 204 in einer produktiven API freigebe, gehe ich eine kurze, sehr nüchterne Checkliste durch. Sie ist simpel, aber genau deshalb wirksam: Die Fehler sind meistens banal, die Folgen nicht.
- Der Endpunkt liefert wirklich keinen Body zurück.
- Der Client erwartet kein JSON, kein HTML und kein leeres Objekt.
- Content-Length und Transfer-Encoding werden nicht vom Server ergänzt.
- Es ist fachlich klar, warum 204 besser ist als 200, 201, 205 oder 304.
- Ein ETag wird nur dann gesetzt, wenn er den Zustand sinnvoll beschreibt.
- Der Test deckt den Erfolgsfall und den Fehlschlag getrennt ab.
Wenn diese Punkte stimmen, ist 204 keine Sonderbehandlung mehr, sondern ein sauberer Baustein in der HTTP-Semantik. Genau so setze ich ihn ein: knapp, eindeutig und nur dort, wo kein Body die Antwort besser machen würde.
