Kod przekierowania wybierz przed publikacją, nie po pierwszym problemie
Cztery kody nie różnią się wyłącznie nazwą. Tabela decyzji łączy trwałość celu, metodę żądania, cache i możliwość przyszłej zmiany.
Odpowiedź 3xx wskazuje klientowi kolejny adres w nagłówku Location, lecz kod opisuje także zamiar autora. RFC 9110 rozróżnia przeniesienie trwałe od tymczasowego oraz zachowanie metod. RFC 9205 zestawia 301, 302, 307 i 308 w dwóch osiach: trwałość oraz możliwość zmiany POST na GET.
Ten artykuł nie wybiera konfiguracji za aplikację. Pokazuje pytania i testy, które trzeba przejść dla konkretnego przepływu. Szczególną ostrożność zachowaj przy metodach zmieniających stan, danych uwierzytelniających i przekierowaniu między różnymi originami.
Najpierw ustal metodę i oczekiwany następny krok
Typowy link w wiadomości lub kodzie QR uruchamia GET. Jeśli endpoint otrzymuje POST, PUT albo inną metodę, nie traktuj go jak zwykłego skrótu marketingowego. Zapisz, czy klient ma ponowić tę samą operację pod nowym adresem, czy przejść do strony wyniku metodą GET. To różne intencje wymagające różnych kodów i ochrony przed powtórzeniem działania.
Sprawdź również, jakie nagłówki i dane mogą przejść do kolejnego żądania. RFC 9110 opisuje modyfikacje podczas automatycznego podążania za przekierowaniem i zwraca uwagę na pola związane z originem, takie jak Authorization oraz Cookie. Nie polegaj na jednym zachowaniu wszystkich klientów.
301 — przeniesienie trwałe, przy którym klient może zmienić POST na GET
Kod 301 informuje, że zasób otrzymał nowy stały URI. Klient z możliwością edycji odsyłaczy może zastąpić stary adres, a odpowiedź jest podatna na ponowne użycie przez cache zgodnie z semantyką HTTP. Przy POST klient może zmienić metodę na GET.
Użyj 301, gdy migracja naprawdę ma być trwała, stary adres nie powinien wrócić, a zachowanie metod jest świadomie uwzględnione. Nie wybieraj go tylko dlatego, że „przekierowanie ma działać szybko”. W krótkim linku do zmiennej kampanii trwałe zapamiętanie celu może utrudnić późniejszą korektę.
302 opisuje cel tymczasowy i również może zmienić POST na GET
Kod 302 mówi klientowi, że zasób znajduje się tymczasowo pod innym URI, więc przyszłe żądania powinny nadal używać adresu pierwotnego. W praktyce jest często stosowany do edytowalnych skrótów otwieranych przez GET. To nie zwalnia z ustawienia świadomej polityki cache i testowania pośredników.
Przy żądaniu POST klient może przejść dalej metodą GET. Jeśli konieczne jest zachowanie metody i treści, 302 nie wyraża tego jednoznacznie. Jeżeli natomiast wynik operacji powinien zostać pokazany jako osobny zasób przez GET, sprawdź semantykę 303 zamiast dobierać kod wyłącznie z tej czwórki.
307 zachowuje metodę przy celu tymczasowym
Kod 307 wskazuje zmianę tymczasową i wymaga, by klient wykonujący automatyczne przekierowanie nie zmieniał metody. POST pozostaje więc POST-em. To przydatne, gdy ta sama operacja ma trafić do tymczasowo innego endpointu i obie strony są przygotowane na identyczne żądanie.
Zachowanie metody może zachować także ryzyko
Nie kieruj w ten sposób wrażliwego żądania na dowolny host. Treść formularza albo dane uwierzytelniające mogą zostać przesłane dalej wbrew intuicji autora. Domena docelowa, dozwolone metody, ochrona przed powtórzeniem oraz reguły usuwania wrażliwych nagłówków wymagają testu, nie założenia.
308 zachowuje metodę i komunikuje trwałość
Kod 308 łączy trwałe przeniesienie z zachowaniem metody. Klient powinien w przyszłości używać nowego URI, a odpowiedź może być heurystycznie buforowana. Stosuj go, gdy oba elementy są zamierzone: cel jest stały, a ta sama metoda ma być ponawiana pod nowym adresem.
W przypadku publicznego skrótu prowadzącego przez GET różnica metod może nie być widoczna w prostym teście przeglądarki. Trwałość nadal ma znaczenie. Raz utrwalone przekierowanie może ominąć późniejszą zmianę po stronie skracarki, zależnie od klienta i cache.
Parametry i fragment nie powinny zmieniać się przypadkiem
Zdefiniuj, czy zapytanie z krótkiego adresu jest odrzucane, kopiowane czy łączone z celem. Bez jawnej reguły można zgubić parametr kampanii albo, co gorsza, przenieść nieoczekiwane dane do innej domeny. RFC 9110 opisuje również dziedziczenie fragmentu, gdy Location nie zawiera własnego fragmentu; uwzględnij to w testach adresów z kotwicą.
Nie twórz celu przez proste sklejanie tekstu otrzymanego od użytkownika. Parsuj, normalizuj i waliduj zgodnie z regułami aplikacji. Wartość nagłówka Location powinna pochodzić z zatwierdzonego rekordu.
Testuj zachowanie, które zobaczy prawdziwy odbiorca
Przygotuj macierz: metoda, kod, cel, cache, query, fragment, klient i wynik. Sprawdź popularną przeglądarkę, klienta mobilnego, skaner QR oraz pośrednika, jeśli występuje w architekturze. Zobacz, czy działa HTTPS, czy nie powstaje pętla, ile jest skoków i jaki host widnieje przed czynnością wrażliwą.
Po zmianie celu sprawdź klienta z pustą oraz istniejącą pamięcią podręczną. Przetestuj odpowiedź na nieznany, wyłączony i wygasły token. Błąd powinien zatrzymać drogę w kontrolowanym miejscu, a nie kierować na stronę główną, która ukrywa fakt niepowodzenia.
Karta wyboru kodu
Zapisz pięć odpowiedzi: czy zmiana jest trwała; czy metoda ma zostać zachowana; czy endpoint przyjmuje tylko GET; jak długo odpowiedź może być buforowana; czy istnieje plan cofnięcia celu. Dopiero potem wybierz kod i politykę cache. Decyzję dołącz do dokumentacji rekordu, aby kolejna osoba nie „naprawiła” jej na podstawie samego numeru.