Kiedy użytkownik nie jest zalogowany i próbuje uzyskać dostęp do strony wymagającej logowania, jaki jest poprawny kod stanu HTTP dla przekierowania do strony logowania?
Pytam, ponieważ żaden z kodów odpowiedzi 3xx określonych przez W3C nie wydaje się spełniać wymagań:
10.3.1 300 wielokrotnych wyborów
Żądany zasób odpowiada dowolnemu z zestawu reprezentacji, z których każda ma swoją własną, określoną lokalizację, i dostarczane są informacje negocjacyjne oparte na agentach (sekcja 12), aby użytkownik (lub agent użytkownika) mógł wybrać preferowaną reprezentację i przekierować jej żądanie do tej lokalizacji.
O ile nie było to żądanie HEAD, odpowiedź POWINNA zawierać encję zawierającą listę charakterystyk zasobów i lokalizacji, z których użytkownik lub agent użytkownika może wybrać najbardziej odpowiednią. Format jednostki jest określony przez typ nośnika podany w polu nagłówka Content-Type. W zależności od formatu i możliwości
agent użytkownika, wybór najwłaściwszego wyboru MOŻE być wykonany automatycznie. Jednak ta specyfikacja nie definiuje żadnego standardu takiego automatycznego wyboru.
Jeśli serwer ma preferowany wybór reprezentacji, POWINIEN dołączyć określony identyfikator URI dla tej reprezentacji w polu Lokalizacja; agenty użytkownika MOGĄ używać wartości pola Lokalizacja do automatycznego przekierowania. Ta odpowiedź może być buforowana, chyba że wskazano inaczej.
10.3.2 301 Przeniesiono na stałe
Do żądanego zasobu został przypisany nowy stały identyfikator URI, a wszelkie przyszłe odwołania do tego zasobu POWINNY używać jednego ze zwróconych identyfikatorów URI. Klienci z możliwością edycji linków powinni automatycznie ponownie łączyć odniesienia do URI żądania z jednym lub większą liczbą nowych odniesień zwróconych przez serwer, jeśli to możliwe. Ta odpowiedź może być buforowana, chyba że wskazano inaczej.
Nowy stały URI POWINIEN być podany w polu Location odpowiedzi. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych identyfikatorów URI.
Jeśli kod stanu 301 zostanie odebrany w odpowiedzi na żądanie inne niż GET lub HEAD, agent użytkownika NIE MOŻE automatycznie przekierowywać żądania, chyba że zostanie to potwierdzone przez użytkownika, ponieważ może to zmienić warunki, na jakich żądanie zostało wysłane.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.10.3.3 302 Znaleziono
Żądany zasób znajduje się tymczasowo pod innym identyfikatorem URI. Ponieważ przekierowanie może być czasami zmieniane, klient POWINIEN nadal używać identyfikatora URI żądania dla przyszłych żądań. Ta odpowiedź może zostać zapisana w pamięci podręcznej tylko wtedy, gdy jest to wskazane w polu nagłówka Cache-Control lub Expires.
Tymczasowy URI POWINIEN być podany w polu Location odpowiedzi. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych URI.
Jeśli kod statusu 302 zostanie odebrany w odpowiedzi na żądanie inne niż GET lub HEAD, agent użytkownika NIE MOŻE automatycznie przekierowywać żądania, chyba że zostanie to potwierdzone przez użytkownika, ponieważ może to zmienić warunki, na jakich żądanie zostało wysłane.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if itbyły odpowiedzią 303, wykonując GET na wartości pola Lokalizacja niezależnie od pierwotnej metody żądania. Kody statusu 303 i 307 zostały dodane dla serwerów, które chcą jednoznacznie wyjaśnić, jakiego rodzaju reakcji oczekuje się od klienta.
10.3.4 303 Zobacz inne
Odpowiedź na żądanie można znaleźć pod innym identyfikatorem URI i POWINNA zostać pobrana przy użyciu metody GET na tym zasobie. Ta metoda istnieje głównie po to, aby dane wyjściowe skryptu aktywowanego metodą POST przekierowywały agenta użytkownika do wybranego zasobu. Nowy identyfikator URI nie jest zastępczym odwołaniem do pierwotnie żądanego zasobu. Odpowiedź 303 NIE MOŻE być buforowana, ale odpowiedź na drugie (przekierowane) żądanie może być buforowana.
W polu Lokalizacja w odpowiedzi NALEŻY podać inny identyfikator URI. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych identyfikatorów URI.
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.10.3.5 304 Nie zmodyfikowano
Jeśli klient wykonał warunkowe żądanie GET i dostęp jest dozwolony, ale dokument nie został zmodyfikowany, serwer POWINIEN odpowiedzieć tym kodem stanu. Odpowiedź 304 NIE MOŻE zawierać treści wiadomości i dlatego jest zawsze zakończona pierwszą pustą linią po polach nagłówka.
Odpowiedź MUSI zawierać następujące pola nagłówka:
- Date, unless its omission is required by section 14.18.1 If aBez zegara serwer pochodzenia przestrzega tych reguł, a serwery proxy i klienci dodają własną datę do każdej odpowiedzi otrzymanej bez niej (jak już określono w [RFC 2068], sekcja 14.19), pamięci podręczne będą działać poprawnie.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (seesekcja 13.3.3), odpowiedź NIE POWINNA zawierać innych nagłówków encji. W przeciwnym razie (tj. Warunkowe GET użyło słabego walidatora), odpowiedź NIE MOŻE zawierać innych nagłówków encji; zapobiega to niespójnościom między treściami jednostek zapisanymi w pamięci podręcznej a zaktualizowanymi nagłówkami.
Jeśli odpowiedź 304 wskazuje, że jednostka nie jest obecnie buforowana, pamięć podręczna MUSI zignorować odpowiedź i powtórzyć żądanie bez warunku.
Jeżeli pamięć podręczna używa odebranej odpowiedzi 304 do aktualizacji wpisu pamięci podręcznej, pamięć podręczna MUSI zaktualizować wpis, aby odzwierciedlić nowe wartości pól podane w odpowiedzi.
10.3.6 305 Użyj proxy
Żądany zasób MUSI być dostępny przez proxy podane w polu Lokalizacja. Pole Location zawiera identyfikator URI proxy. Odbiorca powinien powtórzyć to pojedyncze żądanie za pośrednictwem serwera proxy. 305 odpowiedzi MUSZĄ być generowane tylko przez serwery pochodzenia.
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.10.3.7 306 (nieużywany)
Kod stanu 306 był używany w poprzedniej wersji specyfikacji, nie jest już używany, a kod jest zarezerwowany.
10.3.8 307 Tymczasowe przekierowanie
Żądany zasób znajduje się tymczasowo pod innym identyfikatorem URI. Ponieważ przekierowanie MOŻE być czasami zmieniane, klient POWINIEN nadal używać Request-URI dla przyszłych żądań. Ta odpowiedź może zostać zapisana w pamięci podręcznej tylko wtedy, gdy jest to wskazane w polu nagłówka Cache-Control lub Expires.
Tymczasowy URI POWINIEN być podany w polu Location odpowiedzi. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych identyfikatorów URI, ponieważ wielu klientów użytkowników sprzed HTTP / 1.1 nie rozumie statusu 307. Dlatego notatka POWINNA zawierać informacje niezbędne użytkownikowi do powtórzenia pierwotnego żądania dotyczącego nowego identyfikatora URI.
Jeśli kod statusu 307 zostanie odebrany w odpowiedzi na żądanie inne niż GET lub HEAD, agent użytkownika NIE MOŻE automatycznie przekierowywać żądania, chyba że zostanie to potwierdzone przez użytkownika, ponieważ może to zmienić warunki, na jakich żądanie zostało wysłane.
Używam 302 do teraz, aż znajdę się poprawną odpowiedź.
Aktualizacja i wnioski:
HTTP 302 jest lepszy, ponieważ wiadomo, że ma najlepszą zgodność z klientami / przeglądarkami.