Zusammenfassung

  • Seit 1997 bezeichnet 205 Reset Content eine erfüllte Anfrage, nach der der Client die auslösende Dokumentansicht auf ihren Ausgangszustand zurücksetzen soll.
  • Die Antwort enthält keinen neuen Inhalt; die Fassungen von 2014 und 2022 erläutern den Eingabezyklus und die eindeutige Begrenzung der leeren Nachricht.

Am Schalter geben Sie ein ausgefülltes Formular ab. Die Sachbearbeiterin legt es in die Akte und schiebt sofort ein neues, leeres Blatt über den Tisch. Der Vorgang ist abgeschlossen, der Arbeitsplatz sieht wieder aus wie vor dem ersten Eintrag. Für diese leicht unbarmherzige Effizienz hatte HTTP/1.1 einen eigenen Statuscode: 205 Reset Content.

Der RFC 2068 vom Januar 1997 erklärte die Arbeitsteilung: Der Server hat die Anfrage erfüllt; der Benutzeragent soll die Dokumentansicht zurücksetzen, die sie ausgelöst hat. Als Beispiel diente die wiederholte Eingabe in ein Formular. Ein Mensch füllt Felder aus, sendet die Daten und erhält eine freie Fläche für den nächsten Durchgang. Eine Erfolgsmeldung des Servers wurde zur Anweisung an die lokale Oberfläche.

Entscheidend ist, was auf welcher Seite geschieht. Die abgegebenen Daten gehören zum erfüllten Vorgang auf dem Server. Zurückgesetzt wird die Eingabefläche beim Client. Bereits die erste Spezifikation verbot eine Entität in der 205-Antwort. Der Server lieferte also keine Ersatzseite aus. Er gab dem Browser im Status der Antwort auf, die vorhandene Ansicht für weitere Arbeit herzurichten. Die Akte blieb im Schrank; nur der Tisch wurde leergeräumt.

Der RFC 2616 vom Juni 1999 behielt das Formularbeispiel bei. Gleich daneben steht 204 No Content, bei dem die bestehende Ansicht erhalten bleibt. Beide Antworten verzichten auf einen neuen Nachrichtenkörper, doch der nächste Schritt des Nutzers unterscheidet sich. 205 bevorzugt den Takt einer Eingabeschleife: einen Datensatz abschließen, Felder freigeben, den nächsten Datensatz beginnen. Die Statuszahl regelt damit einen Arbeitsablauf, statt lediglich „Erfolg“ zu sagen.

Der RFC 7231 von 2014 beschrieb den Zielzustand genauer. Die Ansicht soll zu dem ursprünglichen Zustand zurückkehren, in dem sie vom Ursprungsserver empfangen wurde. Als Arbeitsflächen nennt die Norm ein Formular, einen Notizblock und eine Zeichenfläche. Auf ihnen gibt der Nutzer etwas ein oder bearbeitet es, sendet das Ergebnis und beginnt wieder am Ausgangspunkt. Die Spezifikation befasste sich hier mit dem menschlichen Rhythmus wiederholter Netzhandlungen.

Auch eine Antwort ohne Inhalt braucht eine saubere Grenze. Die Fassung von 2014 untersagte eine Nutzlast und nannte drei Möglichkeiten, Länge null auszudrücken: Content-Length: 0, einen leeren Abschluss-Chunk oder das Schließen der Verbindung unmittelbar nach den Headern. Erst wenn der Client das Ende der Antwort kennt, kann er die nächste Nachricht richtig behandeln. Die leere Formularfläche folgt auf eine klar beendete Netzwerknachricht.

Der RFC 9110 von 2022 behielt die Kombination aus erfüllter Anfrage, zurückgesetzter Ansicht und fehlendem Zusatzinhalt. Der Code trägt eine alltägliche Beobachtung durch mehrere Generationen von HTTP: Nach dem Absenden ist oft schon die nächste Eingabe dran. Das Ergebnis wandert in den Bestand des Servers; der Bildschirm stellt den Arbeitsplatz wieder her.

205 klingt nach einem Amt, das nie Mittagspause macht. „Ihr Antrag ist bearbeitet. Hier ist das nächste Formular.“ Hinter dem trockenen Scherz steckt eine klare Trennung: Der abgeschlossene Vorgang bleibt bestehen, während die lokale Schreibfläche erneut verfügbar wird. Eine einzige Statuszeile konnte so eine ganze Warteschlange in Bewegung halten.