Kody statusu 4xx wyjaśnione: co naprawdę znaczą błędy klienta

Co mówi klasa 4xx

RFC 9110 definiuje klasę 4xx jako "Client Error": serwer uważa, że klient popełnił błąd. Obejmuje to żądanie czegoś, co nie istnieje, żądanie bez wymaganych poświadczeń, żądanie, które serwer odrzuca z powodów polityki, oraz żądanie, które jest źle sformułowane albo zbyt duże.

Trzy właściwości tej klasy mają znaczenie podczas debugowania:

• 4xx to ostateczna odpowiedź dla tego żądania, tak jak zostało wysłane. Powtórzenie identycznego żądania zwykle da identyczny kod.
• Treść odpowiedzi ma być wyjaśnieniem zrozumiałym dla człowieka. Dlatego istnieją niestandardowe strony błędów, i dlatego pusta strona 404 to zmarnowana okazja.
• Niektóre odpowiedzi 4xx są domyślnie cache'owalne. RFC 9111 wymienia 404, 405, 410 i 414 wśród kodów, które pamięć podręczna może przechować heurystycznie, więc błędne 404 może przetrwać dłużej niż błąd, który je spowodował.

Kody 4xx, z którymi się spotkasz

• 400 Bad Request: żądanie jest źle sformułowane, a serwer nie potrafi go sparsować. Często zły ciąg zapytania, zbyt duży nagłówek ciasteczka albo zepsute proxy przed aplikacją.
• 401 Unauthorized: uwierzytelnienie jest wymagane, a albo go brakuje, albo jest nieprawidłowe. Serwer musi wysłać nagłówek WWW-Authenticate mówiący klientowi, jak się uwierzytelnić.
• 403 Forbidden: serwer zrozumiał żądanie i odmawia. Poświadczenia nic nie pomogą, bo odmowa to decyzja polityki, nie niepowodzenie uwierzytelnienia.
• 404 Not Found: pod tym adresem URL nie istnieje żadna aktualna reprezentacja, albo serwer nie przyzna, że istnieje. Omówione szczegółowo w poradniku o 404.
• 405 Method Not Allowed: adres URL istnieje, ale nie dla tej metody. Serwer musi wymienić akceptowane metody w nagłówku Allow.
• 408 Request Timeout: klientowi zajęło zbyt długo wysłanie żądania. To co innego niż 504, gdzie opóźnienie leży za serwerem.
• 410 Gone: zasób istniał i został celowo usunięty, i oczekuje się, że to trwałe.
• 413 Content Too Large i 414 URI Too Long: żądanie przekroczyło skonfigurowany limit, zwykle limit przesyłania plików albo rozmiaru nagłówka.
• 429 Too Many Requests: osiągnięto limit częstotliwości. Ten w szczególności uderza w konfiguracje monitoringu.

Kiedy 4xx to naprawdę błędna konfiguracja serwera

Etykieta "błąd klienta" dotyczy ról protokołu, nie winy. Większość kodów 4xx pojawiających się na zdrowej stronie produkcyjnej jest spowodowana czymś po Twojej stronie. Reguła przepisywania albo routingu, która przestała pasować, zamienia poprawne adresy URL w 404 w całym katalogu, a znakiem rozpoznawczym jest 404 na wielu adresach URL naraz, a nie na jednym. Build, który przestaje generować zasób z hashem w nazwie, robi to samo na poziomie pliku: każda strona żąda pliku zwracającego 404, więc strona się renderuje, ale wygląda na zepsutą.

Warstwy bezpieczeństwa odpowiadają za większość reszty. Reguła WAF, filtr botów albo blokada geograficzna mogą zwracać 403 prawdziwemu ruchowi, i łatwo je przeoczyć, bo zwykle przepuszczają adres IP biura. Zmiana uwierzytelniania, która zostawia stronę odpowiadającą 401, choć powinna być publiczna, to 4xx spowodowane całkowicie przez serwer. Podobnie 400 albo 413 z reverse proxy, którego limit nagłówka albo treści jest mniejszy niż aplikacji, dla żądania, które aplikacja by zaakceptowała.

Jak zdiagnozować 4xx na własnej stronie

1. Najpierw odczytaj dokładny kod i nagłówki. Nie oceniaj po stronie błędu, która może być ogólna:

   curl -sS -o /dev/null -D - https://example.com/broken-page

   Pokazuje to linię statusu plus Allow, WWW-Authenticate, Retry-After i wszelkie nagłówki identyfikujące serwer lub CDN.
2. Zdecyduj, czy to jeden URL, czy wzorzec. Jeden URL wskazuje na link albo usuniętą stronę. Cały prefiks ścieżki wskazuje na routing, uprawnienia albo wdrożenie.
3. Sprawdź, kto odpowiedział. Porównaj odpowiedź z brzegu CDN z odpowiedzią z origin. 403, które istnieje tylko na brzegu, to reguła WAF albo botów, nie Twoja aplikacja.
4. Spróbuj innej tożsamości klienta. Inny user agent, sesja bez uwierzytelnienia albo inna sieć mogą zmienić kod z 403 na 200, co natychmiast lokalizuje blokadę.
5. Odczytaj linię logu serwera dla tego żądania. Logi serwera WWW i aplikacji zapisują, która reguła albo handler wyprodukowały kod. To krok, który zwykle kończy dochodzenie.
6. Napraw, a potem wyczyść pamięci podręczne. Ponieważ kilka kodów 4xx jest cache'owalnych, poprawiona strona może wciąż serwować stary błąd z CDN albo pamięci podręcznej przeglądarki, dopóki wpis nie zostanie unieważniony.

Znajdowanie stron 4xx, których nigdy nie odwiedzasz

4xx nie wyłącza serwera, dlatego pozostaje niezauważone. Strona się ładuje, strona główna jest w porządku, a jedna sekcja zwraca 404 albo 403 dla wszystkich oprócz Ciebie. Zaplanowana kontrola HTTP porównuje otrzymany kod z oczekiwanym, więc strona, która zaczyna odpowiadać 403 zamiast 200, wywołuje alert zamiast czekać na zgłoszenie wsparcia. Ma też znaczenie, skąd sprawdzenie jest uruchamiane. HostTracker sprawdza z ponad 300 punktów kontrolnych w 158 miastach, więc blokada geograficzna albo regionalna reguła WAF ujawnia się jako realna różnica między lokalizacjami zamiast zagadki. Jeśli zawodzącym kodem jest zamiast tego 500, 502 albo 503, przyczyna leży po stronie serwera, a poradnik o rodzinie 5xx to miejsce, od którego zacząć.