Zusammenfassung

  • RFC 1945 vom Mai 1996 nannte 302 „Moved Temporarily“ und verlangte eine Bestätigung, bevor ein POST automatisch umgeleitet wurde. RFC 2068 vom Januar 1997 behielt diese Vorsicht bei, vermerkte bereits Clients, die POST in GET verwandelten, und definierte 303 „See Other“ für den Abruf einer anderen Ressource per GET.
  • RFC 2616 vom Juni 1999 nannte 302 nun „Found“ und erklärte, die meisten bestehenden User Agents behandelten 302 wie 303: Sie riefen die Location mit GET ab, unabhängig von der ursprünglichen Methode. 307 „Temporary Redirect“ kam hinzu, um die Methodentreue eindeutig anzuzeigen. 303 war schon 1997 definiert.
  • RFC 9110 vom Juni 2022 erlaubt aus historischen Gründen weiterhin, nach 302 von POST zu GET zu wechseln. Bei einem automatisch befolgten 307 darf der Client die Methode nicht ändern. Diese Wahl entscheidet, ob der Formularinhalt an der neuen Adresse ankommt.

Die Adresse wechselte. Was geschah mit der Anfrage?

Die HTTP/1.0-Spezifikation RFC 1945 vom Mai 1996 bezeichnete 302 als „Moved Temporarily“. Eine Ressource befand sich im Moment unter einer anderen URL, die der Server mit Location nannte. Weil die Verschiebung nicht dauerhaft sein musste, sollte der Client künftig wieder die ursprüngliche Adresse verwenden. Bei GET lässt sich das wie ein Umleitungsschild lesen: hier gefragt, dort das Dokument geholt.

POST bringt ein ausgefülltes Formular und häufig eine gewünschte Handlung mit. Wenn der Server eine andere URL nennt, soll der Browser denselben Inhalt noch einmal senden? Der Text von 1996 untersagte die automatische Umleitung eines POST nach 302, sofern der Nutzer sie nicht bestätigen konnte. Der neue Empfänger konnte die Bedingungen ändern, unter denen der Nutzer die Daten abgeschickt hatte.

Eine Weiterleitung trifft also zwei Entscheidungen. Location nennt den Ort der nächsten Anfrage. Methode und Inhalt legen fest, was dort geschieht. Bleibt POST erhalten, kann das Formular an den neuen Server gelangen. Wird daraus GET, ruft der Client eine Ressource ab, ohne dieselben Daten erneut zu übermitteln. Ein bloßer Pfeil zwischen URLs lässt diese zweite Entscheidung unsichtbar werden.

Die ursprüngliche Regel bremste das automatische Weitersenden. Wer „Absenden“ drückt, stimmt damit nicht zwangsläufig einer zweiten Übertragung an ein anderes Ziel zu. Websites wollten jedoch nach der Verarbeitung eines Formulars auch Ergebnisse anzeigen. In dieser alltäglichen Situation musste ein Browser auf das Umleitungsschild reagieren.

303 war eindeutig, 302 wurde anders benutzt

Die erste HTTP/1.1-Spezifikation RFC 2068 vom Januar 1997 behielt den Namen „Moved Temporarily“ bei und verlangte eine Bestätigung vor der automatischen Weiterleitung einer Anfrage, die weder GET noch HEAD war. Eine Anmerkung dokumentierte den Streit mit der Wirklichkeit: Einige HTTP/1.0-Clients machten aus POST beim Folgen von 302 ein GET. Nach dem beschriebenen Regelwerk war das fehlerhaft.

Im selben RFC stand bereits 303 „See Other“. Ein Server konnte eine per POST ausgelöste Aktion erledigen und dann auf eine andere Ressource zeigen, die mit GET gelesen werden sollte. Das Ergebnis eines durch POST gestarteten Skripts war ein Hauptfall. Die neue URI war nicht einfach ein weiterer Name für die erste Ressource. Sie lieferte eine eigenständige Darstellung des Resultats.

Ein Browser, der 302 zu GET umdeutete, erreichte etwas Ähnliches ohne den ausdrücklichen Code des Servers. Wenn die Aktion schon abgeschlossen war, konnte das passen. Wenn der Server die ursprüngliche POST-Operation am temporären Ziel fortsetzen wollte, kam dort aber ein Leseauftrag an. Dieselbe Zahl stand für zwei verschiedene Folgeschritte. Die Spezifikation von 1997 machte den Widerspruch sichtbar, während er noch in den Clients lebte.

1999 saß die Mehrheit der Clients am Tisch

Der HTTP/1.1-RFC 2616 vom Juni 1999 gab 302 den Namen „Found“. Wichtiger war seine Anmerkung: Die Texte von 1996 und 1997 ließen keine Änderung der Methode zu, doch die meisten bestehenden User Agents behandelten 302 wie 303. Sie machten ein GET auf die Location, unabhängig von der ursprünglichen Methode. „Die meisten“ ist die Einschätzung des RFC selbst; eine Liste der einzelnen Browserfassungen steht dort nicht.

Die Autoren gaben Servern klarere Wahlmöglichkeiten. 303 blieb die Anweisung, eine andere Ressource mit GET zu lesen, etwa die Ergebnisdarstellung nach POST. Diesen Code gab es schon 1997. Der neue Code 307 „Temporary Redirect“ sollte das Gegenteil klar kennzeichnen: vorübergehend an eine andere URI, aber ohne die ursprüngliche Anfragemethode zu ändern. Die Fortsetzung einer Operation und der Abruf ihres Resultats bekamen verschiedene Nummern.

302 verschwand nicht. RFC 2616 merkte sogar an, dass viele ältere Clients 303 nicht verstanden. Wer mit ihnen zusammenarbeiten musste, könne 302 verwenden, weil die meisten ihn wie 303 behandelten. Der Standard hatte eine sauber benannte Alternative und empfahl unter Kompatibilitätsdruck trotzdem die mehrdeutige alte Zahl. Installierte Software übte eine eigene Form von Stimmrecht aus.

Für einen Formulardienst war das keine akademische Feinheit. Nach erfolgreicher Verarbeitung lädt ein GET eine Bestätigungsseite, ohne den Formularinhalt zu wiederholen. Soll die Operation erst am temporären Ziel erfolgen, müssen POST und Inhalt dorthin gelangen. Ein 302 überließ einen Teil dieser Entscheidung dem Verhalten des jeweiligen Browsers.

Die historische Erlaubnis steht noch 2022 da

Die HTTP-Semantik in RFC 9110 vom Juni 2022 trägt den alten Konflikt weiter. Ein User Agent darf aus historischen Gründen nach 302 POST in GET ändern. Das ist eine Erlaubnis, kein Befehl an alle Clients. Wenn der Server genau diese Umwandlung nicht will, verweist der Text auf 307. Bei einer automatischen Weiterleitung nach 307 darf der Client die Methode nicht ändern.

303 beschreibt derselbe RFC als indirekte Antwort: Ein Client kann eine andere Ressource, gewöhnlich mit GET oder HEAD, abrufen und das Ergebnis als Antwort auf die ursprüngliche Anfrage zeigen. Die historische Erläuterung schildert die frühen Unterschiede zwischen Clients, die POST bewahrten, und solchen, die zu GET wechselten. Für 301 und 302 setzte sich Letzteres als Praxis durch. Der spätere Normtext räumte dieser Praxis einen Platz ein.

POST zu bewahren ist dabei keine allgemeine Sicherheitsregel. Unter 307 kann der Formularinhalt an die URI in Location gelangen. Wenn die Handlung dort weitergehen soll, ist genau das gewünscht. Steht das Ziel unter anderer Kontrolle, muss der Server diese Datenbewegung bedenken. Der Wechsel zu GET verhindert die Wiederholung des Inhalts, führt aber eine am Ziel nötige POST-Operation nicht aus. Die Nummer hat der beabsichtigten Transaktion zu dienen.

Die vier offiziellen Texte nennen nicht, mit welcher Browserfassung die Methode erstmals geändert wurde. Datierte Implementierungsunterlagen würden die Chronologie einzelner Programme liefern. Die Standards belegen bereits die Hauptlinie: Bremse 1996, Abweichung im Text von 1997, Mehrheitspraxis und 307 im Jahr 1999, historische Erlaubnis noch 2022.

Nicht nur die Seite wurde weitergeleitet

Man zeichnet 3xx-Antworten gern als Wegweiser zu einer verschobenen Seite. Der Fall 302 betrifft auch die Handlung im Request. POST kann Nutzerdaten und einen Entschluss tragen. Dieselbe Anfrage an eine andere URI zu senden ist etwas anderes, als dort mit GET eine Seite abzurufen. Location bestimmt den Ort; Statuscode und Browserverhalten bestimmen, was die Grenze passiert.

Die laufenden Clients machten eine Antwort verbreitet. Die Verfasser des Protokolls konnten das nicht durch Wiederholung ihres früheren Absatzes auslöschen. Sie benannten die Abweichung, ergänzten einen eindeutigen Code für die Beibehaltung der Methode und erlaubten schließlich das historische POST-zu-GET-Verhalten bei 302. Ein Standard muss mit Software sprechen, die bereits auf dem Netz arbeitet.

Die praktische Lesart umfasst drei Nachbarn: 302 kann aus POST ein GET machen; 303 verlangt den Abruf eines anderen Ergebnisses; 307 bewahrt bei automatischer temporärer Weiterleitung die Methode. Dass die älteste Zahl unklar blieb, lag an den Antworten, die Browser gegeben hatten, bevor der Normtext nachzog.

Quellen