303 See Other: przekierowanie po POST formularza

Do czego służy 303

303 tak naprawdę nie dotyczy przenoszenia zasobu. Chodzi o oddzielenie akcji od jej wyniku. Klient wysyła POST, serwer wykonuje akcję, a potem zamiast zwracać wynik w odpowiedzi na POST, odpowiada 303 wraz z nagłówkiem Location. Klient wykonuje świeże żądanie GET do tego adresu, a pasek adresu przeglądarki kończy na zwykłym URL, który można dodać do zakładek i odświeżyć.

Kluczowa zasada dotyczy metody: niezależnie od tego, jaka była metoda pierwotnego żądania, kolejne żądanie do adresu URL z Location jest zawsze GET. To odwrotność 307 i 308, które wymagają zachowania pierwotnej metody i treści.

Post/Redirect/Get i problem, który rozwiązuje

Bez przekierowania po POST strona wyniku należy do żądania POST, co powoduje znane problemy:

• Naciśnięcie odświeżenia ponownie wysyła formularz, więc zamówienie zostaje złożone albo komentarz opublikowany dwukrotnie. Przeglądarki ostrzegają przed tym oknem dialogowym "potwierdź ponowne przesłanie formularza", co samo w sobie jest słabym doświadczeniem.
• Strony nie da się dodać do zakładek ani udostępnić, bo URL nie opisuje treści.
• Przycisk wstecz trafia na monit o ponowne przesłanie zamiast na poprzednią stronę.

Post/Redirect/Get naprawia wszystkie te problemy. POST wykonuje akcję i odpowiada 303; przeglądarka wykonuje GET na URL wyniku; odświeżenie teraz po prostu ponownie pobiera nieszkodliwą stronę. Dlatego niemal każdy framework ma pomocnik "przekieruj po zapisie".

303 vs 302 vs 307

• 302 Found to przekierowanie tymczasowe, którego obsługa metody jest historycznie niejednoznaczna. Większość klientów zamienia POST na GET, gdy za nim podąża, co zwykle jest tym, czego chciałeś, ale standard tego nie wymaga. Wiele frameworków wciąż emituje 302 dla schematu post-a-potem-przekierowanie i w praktyce działa.
• 303 See Other czyni to zachowanie jawnym i wymaganym. Jeśli Twoją intencją jest "nie powtarzaj mojego POST, idź i pobierz to przez GET", 303 mówi to jednoznacznie.
• 307 Temporary Redirect to ten, którego tutaj należy unikać. Wymaga powtórzenia POST wobec nowego adresu URL, co dla wysłania formularza oznacza wykonanie akcji dwukrotnie.

Jedno praktyczne zastrzeżenie: 303 zostało wprowadzone w HTTP/1.1, więc klient mówiący HTTP/1.0 może go nie rozumieć. Niektóre frameworki z tego powodu domyślnie używają 302. We współczesnym internecie rzadko jest to realne ograniczenie, ale wyjaśnia rozbieżność domyślnych ustawień między językami.

Gdzie jeszcze pojawia się 303

• API rozpoczynające długo trwającą pracę. POST uruchamia zadanie i odpowiada 303 z adresem URL statusu tego zadania, albo 202 z adresem URL statusu w treści. Oba wzorce są w użyciu; 303 ma tę przewagę, że przeglądarka podąża za nim automatycznie.
• Przepływy OAuth i logowania. Niektóre serwery autoryzacji przekierowują z powrotem do aplikacji klienckiej przez 303, żeby callback był pobierany przez GET niezależnie od tego, jak żądanie dotarło.
• Konfiguracje danych powiązanych i negocjacji treści, które rozróżniają rzeczywisty obiekt od dokumentu go opisującego i używają 303, żeby wysłać klientów od identyfikatora do dokumentu.

Jak tego używać i to zweryfikować

1. Po udanym POST zwróć 303 z absolutnym Location wskazującym na stronę wyniku. Nie renderuj wyniku bezpośrednio.
2. Uczyń cel idempotentnym. Będzie pobierany ponownie przy każdym odświeżeniu i każdej nawigacji wstecz, więc musi być bezpieczny do wielokrotnego GET.
3. Przenoś jednorazową wiadomość, taką jak "Twoje zmiany zostały zapisane", w stanie sesji albo parametrze zapytania, a nie w treści przekierowania. Treść odpowiedzi 303 zwykle nie jest wyświetlana.
4. Zweryfikuj kod i cel:

   curl -si -X POST -d "name=test" https://example.com/submit | grep -Ei "^(HTTP|location)"

   Powinieneś zobaczyć HTTP/1.1 303 See Other i URL wyniku.
5. Podążaj za nim i potwierdź, że drugie żądanie to GET zwracający 200. Jeśli w logach serwera widzisz powtórzony POST, reguła to 307 i wymaga zmiany.
6. Sprawdź, czy cel sam nie jest przekierowaniem. 303 w 301 w rzeczywistą stronę to trzy przejścia dla jednego wysłania formularza.

Monitorowanie punktów końcowych za formularzem

Zepsuty przepływ post-a-potem-przekierowanie jest niewidoczny dla sprawdzenia, które pobiera tylko stronę główną. Strona działa, formularz się renderuje, a na awarię trafiają tylko ci, którzy go wysyłają. Wyłap to wcześnie, obserwując punkty końcowe za akcją, takie jak strona wyniku, adres URL potwierdzenia i trasa statusu zadania, i asercjonując oczekiwany kod statusu oraz treść na każdym z nich. HostTracker oferuje 13 typów monitorów i powiadamia e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i inne kanały. Sprawdź, co zwraca dowolny URL, za pomocą narzędzia do kontroli HTTP, i przeczytaj 301 vs 302 oraz pełny poradnik o rodzinie przekierowań 3xx dla sąsiednich kodów.