300 Multiple Choices: kod, którego niemal nigdy nie zobaczysz

Do czego zaprojektowano ten kod

HTTP obsługuje negocjację treści: ten sam URL może mieć kilka reprezentacji różniących się formatem, językiem albo kodowaniem. Zwykle decyduje serwer, na podstawie nagłówków klienta Accept, Accept-Language i Accept-Encoding, i zwraca wybraną wersję z kodem 200. To negocjacja prowadzona przez serwer, i tak działa większość sieci.

300 Multiple Choices pokrywa drugie podejście, negocjację prowadzoną przez agenta. Zamiast wybierać, serwer odpowiada listą dostępnych reprezentacji i pozwala wybrać klientowi albo użytkownikowi. Odpowiedź może zawierać nagłówek Location wskazujący preferowaną opcję serwera, za którym klient może, ale nie musi, podążyć.

Dlaczego niemal nigdy go nie widać

Standard nigdy nie określił maszynowo czytelnego formatu listy wyborów. Bez uzgodnionego formatu przeglądarka nie ma czego parsować, więc żadna popularna przeglądarka nie implementuje interfejsu wyboru dla 300. Przeglądarki zwykle wyświetlają treść odpowiedzi jako zwykłą stronę albo podążają za nagłówkiem Location, jeśli jest obecny, co sprawia, że 300 zachowuje się jak słabe przekierowanie. Frameworki aplikacji i CDN-y nie emitują go w domyślnych konfiguracjach, a negocjacja prowadzona przez serwer rozwiązuje ten sam problem niewidocznie i lepiej, więc nikt nie ma powodu, żeby się przełączać.

300 wciąż pojawia się w kilku miejscach:

• mod_negotiation Apache z włączonym MultiViews, gdy kilka plików pasuje do żądania takiego jak /logo, a moduł nie potrafi ich uszeregować. Generuje wtedy listę kandydatów w HTML.
• Ręcznie pisane API, które celowo zwracają listę JSON alternatywnych adresów URL zasobów, używając 300 jako semantycznej wskazówki, a nie oczekując, że jakikolwiek klient obsłuży to natywnie.
• Zestawy testów i narzędzia zgodności z protokołem, które ćwiczą każdy zdefiniowany kod statusu.

Dlaczego ludzie szukają kodu statusu 300

Większość wyszukiwań "kod statusu 300" wcale nie dotyczy prawdziwego 300. Ta liczba to początek rodziny przekierowań, więc osoby, które zobaczyły przekierowanie w narzędziu przeglądarki, w logu albo w crawlerze SEO i zapamiętały "jakieś 300-coś", szukają najpierw 300. Zwykle mają do czynienia z:

• 301, przekierowaniem stałym, zgłoszonym przez crawler SEO jako część łańcucha.
• 302, przekierowaniem tymczasowym, domyślnym dla wielu frameworków.
• 304, które w ogóle nie jest przekierowaniem, tylko odpowiedzią walidacji pamięci podręcznej.
• Podsumowaniem crawlera, które grupuje wszystko pod nagłówkiem "3xx", co potem jest odczytywane jako "300".

Jeśli próbujesz ustalić, które przekierowanie zwraca dany URL, poradnik 301 vs 302 to ten, którego szukasz.

Jak sprawdzić, czy naprawdę masz 300

1. Poproś o nagłówki bez podążania za jakimkolwiek przekierowaniem i przeczytaj dokładną liczbę:

   curl -sI https://example.com/some-path | grep -Ei "^(HTTP|location|link|alternates)"

   Prawdziwe 300 pokazuje HTTP/1.1 300 Multiple Choices. Cokolwiek innego to inny kod i inny poradnik.
2. Jeśli to naprawdę 300 i nie było to zamierzone, najpierw sprawdź Apache. Wyłączenie MultiViews dla tego katalogu albo nadanie plikowi jawnego rozszerzenia w URL usuwa niejednoznaczność, która wyzwala negocjację.
3. Jeśli chcesz, żeby wybierał serwer, zachowaj negocjację prowadzoną przez serwer: zwróć 200 z wybraną reprezentacją i nagłówek Vary wymieniający nagłówki żądania, na których negocjowałeś, żeby pamięci podręczne przechowywały warianty osobno.
4. Jeśli chcesz odesłać klientów gdzie indziej, użyj prawdziwego przekierowania. Trwałe przenosiny dostają 301 albo 308, tymczasowe 302 albo 307. Nie używaj 300 jako przekierowania, bo klienci nie są zobowiązani za nim podążyć.
5. Napraw niejednoznaczność u źródła. 300 niemal zawsze oznacza, że dwa pliki albo dwie trasy rywalizują o ten sam URL, a trwałą naprawą jest uczynienie URL jednoznacznym.

Wyłapanie nieoczekiwanego 300 po wdrożeniu

Nieoczekiwane 300 zwykle przychodzi razem z aktualizacją serwera albo zmianą konfiguracji, i nikt tego nie zauważa: strona może wciąż wyglądać w przeglądarce mniej więcej dobrze, podczas gdy crawlery i klienci API dostają odpowiedź, której nie mogą wykorzystać. Zewnętrzne sprawdzenie, które zapisuje dokładny kod statusu dla każdego URL, ujawnia zmianę przy pierwszym uruchomieniu po wdrożeniu. HostTracker monitoruje witryny od 2004 roku i uruchamia sprawdzenia z ponad 300 punktów kontrolnych w 158 miastach. Sprawdź, co URL zwraca właśnie teraz, za pomocą narzędzia sprawdzenia HTTP, albo przeczytaj pełny poradnik o rodzinie przekierowań 3xx.