303 See Other: die Weiterleitung nach einem Formular-POST

2026-09-04 Aktualisiert: 2026-09-14

303 See Other teilt dem Client mit, dass der Request bearbeitet wurde und das Ergebnis unter einer anderen URL liegt, die er mit GET abrufen soll. Es ist die korrekte Antwort auf eine Formularübermittlung, die den Besucher auf einer Ergebnis- oder Bestätigungsseite landen lassen soll, statt ihn auf dem POST zu belassen.

Wofür 303 da ist

Bei einem 303 geht es eigentlich nicht darum, eine Ressource zu verschieben. Es geht darum, eine Aktion von ihrem Ergebnis zu trennen. Der Client sendet einen POST, der Server führt die Aktion aus, und statt das Ergebnis in der POST-Antwort zurückzugeben, antwortet er mit 303 und einem Location-Header. Der Client stellt eine frische GET-Anfrage an diese Adresse, und die Adressleiste des Browsers landet auf einer gewöhnlichen URL, die sich mit einem Lesezeichen versehen und neu laden lässt.

Die entscheidende Regel ist die Methode: Was auch immer die ursprüngliche Request-Methode war, der Folge-Request an die Location-URL ist ein GET. Das ist das Gegenteil von 307 und 308, die verlangen, dass die ursprüngliche Methode und der Body erhalten bleiben.

Post/Redirect/Get, und das Problem, das es löst

Ohne Weiterleitung nach einem POST gehört die Ergebnisseite zum POST-Request, was bekannte Probleme verursacht:

Neuladen sendet das Formular erneut ab, sodass die Bestellung doppelt aufgegeben oder der Kommentar doppelt gepostet wird. Browser warnen davor mit einem Dialog "Formularübermittlung bestätigen", der selbst eine schlechte Erfahrung ist.
Die Seite lässt sich nicht mit einem Lesezeichen versehen oder teilen, weil die URL den Inhalt nicht beschreibt.
Der Zurück-Button landet auf einer Aufforderung zur erneuten Übermittlung statt auf der vorherigen Seite.

Post/Redirect/Get behebt alle drei. Der POST führt die Aktion aus und antwortet mit 303; der Browser holt die Ergebnis-URL per GET; ein Neuladen ruft jetzt nur noch eine harmlose Seite erneut ab. Deshalb hat fast jedes Framework einen Helfer "nach dem Speichern weiterleiten".

303 gegenüber 302 gegenüber 307

302 Found ist eine temporäre Weiterleitung, deren Methodenbehandlung historisch mehrdeutig ist. Die meisten Clients machen beim Folgen aus einem POST ein GET, was meist gewünscht ist, aber der Standard verlangt es nicht. Viele Frameworks geben für Post-dann-Redirect weiterhin 302 aus, und es funktioniert in der Praxis.
303 See Other macht dieses Verhalten explizit und verbindlich. Wenn Ihre Absicht lautet "wiederhole meinen POST nicht, hol dir stattdessen das hier per GET", sagt 303 das unmissverständlich.
307 Temporary Redirect ist hier das, was zu vermeiden ist. Es verlangt, dass der POST gegen die neue URL wiederholt wird, was bei einer Formularübermittlung bedeutet, die Aktion zweimal auszuführen.

Ein praktischer Vorbehalt: 303 wurde mit HTTP/1.1 eingeführt, ein Client, der HTTP/1.0 spricht, versteht es also möglicherweise nicht. Manche Frameworks setzen deshalb standardmäßig auf 302. Im modernen Web ist das selten eine echte Einschränkung, erklärt aber die unterschiedlichen Vorgaben, die Sie zwischen Sprachen sehen werden.

Wo 303 sonst noch auftaucht

APIs, die langlaufende Arbeit starten. Ein POST stößt einen Job an und antwortet mit 303 und der Status-URL dieses Jobs, oder mit 202 und einer Status-URL im Body. Beide Muster sind im Einsatz; 303 hat den Vorteil, dass ein Browser ihm automatisch folgt.
OAuth- und Anmelde-Abläufe. Manche Autorisierungsserver leiten mit einem 303 zurück zur Client-Anwendung, damit der Callback per GET abgerufen wird, unabhängig davon, wie der Request ankam.
Linked-Data- und Content-Negotiation-Aufbauten, die ein reales Ding vom Dokument unterscheiden, das es beschreibt, und 303 nutzen, um Clients vom Bezeichner zum Dokument zu schicken.

Wie Sie es einsetzen und überprüfen

Geben Sie nach einem erfolgreichen POST 303 mit einer absoluten Location zurück, die auf die Ergebnisseite zeigt. Rendern Sie das Ergebnis nicht inline.
Machen Sie das Ziel idempotent. Es wird bei jedem Neuladen und jeder Zurück-Navigation erneut abgerufen, muss also sicher wiederholt per GET abrufbar sein.
Tragen Sie jede einmalige Nachricht, etwa "Ihre Änderungen wurden gespeichert", im Sitzungszustand oder einem Query-Parameter statt im Weiterleitungs-Body. Ein 303-Antwort-Body wird normalerweise nicht angezeigt.
Überprüfen Sie Code und Ziel:
```
curl -si -X POST -d "name=test" https://example.com/submit | grep -Ei "^(HTTP|location)"
```
Sie sollten HTTP/1.1 303 See Other und die Ergebnis-URL sehen.
Folgen Sie ihr und bestätigen Sie, dass der zweite Request ein GET ist, das 200 zurückgibt. Sehen Sie einen wiederholten POST in Ihren Server-Logs, ist die Regel ein 307 und muss geändert werden.
Prüfen Sie, dass das Ziel nicht selbst eine Weiterleitung ist. Ein 303 in ein 301 in die echte Seite sind drei Umläufe für eine Formularübermittlung.

Die Endpunkte hinter einem Formular überwachen

Ein defekter Post-dann-Redirect-Ablauf ist für eine Prüfung, die nur die Startseite abruft, unsichtbar. Die Website ist erreichbar, das Formular rendert, und nur wer es abschickt, trifft auf den Fehlschlag. Erfassen Sie es früh, indem Sie die Endpunkte hinter der Aktion überwachen, etwa die Ergebnisseite, die Bestätigungs-URL und die Job-Status-Route, und bei jedem den erwarteten Statuscode und Inhalt prüfen. HostTracker bietet 13 Monitortypen und benachrichtigt per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr. Prüfen Sie, was eine beliebige URL zurückgibt, mit dem HTTP-Check-Tool, und lesen Sie 301 gegenüber 302 sowie die vollständige Anleitung zur 3xx-Weiterleitungsfamilie für die benachbarten Codes.