400 Bad Request: co oznacza i jak naprawić

Co oznacza 400 Bad Request

RFC 9110 definiuje 400 jako sposób serwera na powiedzenie, że żądania nie dało się zrozumieć z powodu wadliwej składni. Kluczowe słowo to składnia: serwer nie ocenia, kim jesteś, co wolno Ci zrobić ani czy zasób istnieje. Mówi, że samo żądanie, jako bajty na łączu, nie parsuje się jako poprawne żądanie HTTP. Może to dotyczyć linii żądania, nagłówków albo treści, w zależności od tego, gdzie parser się poddaje.

Jak pojawia się błąd

Przeglądarki renderują dowolną prostą stronę błędu, którą serwer odsyła przy 400; nie ma dedykowanej strony na poziomie przeglądarki, jak przy awarii DNS czy certyfikatu, bo połączenie się udało i odpowiedź faktycznie nadeszła. Częsty wariant brzmi dokładnie "400 Bad Request - request header or cookie too large", co wprost nazywa przyczynę. Z linii poleceń:

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

Logi serwera są tu najbardziej użytecznym dowodem, bo w przeciwieństwie do awarii handshake'u TLS żądanie faktycznie dotarło do warstwy aplikacji i zostaje zalogowane, często razem z konkretnym nagłówkiem albo linią, której nie udało się sparsować.

Co powoduje 400 Bad Request

Z perspektywy odwiedzającego, w kolejności, w jakiej najczęściej faktycznie się na nie trafia:

• Zbyt duże albo uszkodzone ciasteczka. Lata nagromadzonych ciasteczek dla jednej domeny albo ciasteczko zniekształcone przez rozszerzenie albo złe przekierowanie regularnie produkują dokładnie komunikat "400 Bad Request - request header or cookie too large", gdy całkowity rozmiar nagłówków przekroczy limit serwera.
• Błędnie wpisany albo źle zakodowany URL. Przypadkowy znak, niezakodowana spacja albo zepsuta sekwencja kodowania procentowego w pasku adresu albo we wklejonym linku mogą nie sparsować się jako poprawna składnia.
• Rozszerzenie przeglądarki modyfikujące żądania. Blokery reklam, narzędzia prywatności i niektóre rozszerzenia VPN przepisują nagłówki albo linię żądania, a błąd w jednym z nich może dostarczyć serwerowi coś wadliwego.
• Zbuforowane przekierowanie wskazujące na zepsuty URL. Przeglądarka podąża za nieaktualnym przekierowaniem do URL-a, który sam w sobie jest nieprawidłowy, a 400 pojawia się na miejscu docelowym, nie na linku, który faktycznie kliknąłeś.
• Plik przesyłany większy, niż pozwala serwer. Niektóre konfiguracje serwera odpowiadają na zbyt duży upload kodem 400 zamiast bardziej konkretnym 413 Payload Too Large.

Z perspektywy właściciela witryny, w przybliżeniu w kolejności, którą warto sprawdzić najpierw:

• Limity rozmiaru nagłówków albo ciasteczek ustawione zbyt nisko w stosunku do tego, co aplikacja faktycznie wysyła, zwłaszcza po dodaniu ciasteczek śledzących, JWT-ów w nagłówkach albo mechanizmu sesji, który rośnie z czasem.
• Nieprawidłowy albo brakujący nagłówek Host, który może wyprodukować reverse proxy albo źle skonfigurowany klient, i którego większość serwerów wymaga, żeby w ogóle wytrasować żądanie.
• Content-Length niezgodny z rzeczywiście wysłaną treścią, co może spowodować zepsuty klient albo błędne proxy po drodze.
• Reguły zapory aplikacji webowej albo ModSecurity odrzucające żądanie, którego składnia wygląda dla człowieka w porządku, ale pasuje do wzorca obronnego, który WAF traktuje jako wadliwy.
• API celowo odrzucające wadliwy JSON kodem 400. To zachowanie poprawne, nie błąd: treść żądania, która nie parsuje się jako poprawny JSON, albo której brakuje wymaganego pola sprawdzanego przez API na poziomie składni, powinna z założenia zwracać 400.

Jak rozpoznać, kto zawinił

Odtwórz to samo żądanie z czystego środowiska: okno przeglądania prywatnego bez rozszerzeń i bez nagromadzonych ciasteczek, albo zwykłe wywołanie curl pod ten sam URL. Jeśli czyste żądanie się powiedzie, przyczyna była lokalna, najczęściej ciasteczka albo rozszerzenie. Jeśli zawodzi identycznie z czystego klienta i skądinąd zupełnie, własne limity albo reguły serwera odrzucają zgodnie sformułowane żądanie, a najszybszym sposobem potwierdzenia tego na większą skalę jest uruchomienie kontroli HTTP z kilku lokalizacji naraz i porównanie kodu statusu zwróconego przez każdą z nich.

Jak naprawić 400 Bad Request

Jeśli jesteś odwiedzającym

1. Wyczyść ciasteczka dla witryny najpierw, bo zbyt duże albo uszkodzone ciasteczka są zdecydowanie najczęstszą przyczyną. Większość przeglądarek pozwala wyczyścić ciasteczka dla jednej witryny bez wylogowywania wszędzie indziej.
2. Spróbuj ponownie w oknie prywatnym albo incognito. Czyste okno nie ma nagromadzonych ciasteczek i, zależnie od przeglądarki, domyślnie wyłącza większość rozszerzeń, co izoluje obie częste przyczyny naraz.
3. Sprawdź URL pod kątem literówek albo przypadkowych znaków, zwłaszcza po wklejeniu linku skądś, gdzie mogły zostać dodane parametry śledzące albo zepsute kodowanie.
4. Wyłączaj rozszerzenia po jednym, jeśli błąd utrzymuje się w normalnym oknie, ale nie w przeglądaniu prywatnym, żeby znaleźć, które z nich przepisuje żądanie.
5. Wypróbuj inne urządzenie albo sieć, żeby wykluczyć captive portal albo lokalne proxy niezwiązane w ogóle z witryną.

Jeśli prowadzisz witrynę

1. Podnieś limity nagłówków i buforów, jeśli aplikacja rzeczywiście ich potrzebuje. Na nginx:

   large_client_header_buffers 4 16k;

   Na Apache:

   LimitRequestFieldSize 16384

   Na IIS sprawdź zarówno maxRequestLength w web.config dla treści żądania, jak i ustawienie rejestru HTTP.sys MaxFieldLength dla pojedynczych pól nagłówka.
2. Ogranicz to, co faktycznie wysyłasz w ciasteczkach i nagłówkach, zamiast tylko podnosić sufit. Przycięcie nieaktualnych ciasteczek, przeniesienie dużych tokenów poza nagłówki i ustawienie krótszego czasu życia ciasteczek zapobiega powrotowi problemu w miarę wzrostu ruchu.
3. Sprawdź obsługę nagłówka Host na reverse proxy albo load balancerze i potwierdź, że przekazuje do aplikacji poprawną, oczekiwaną wartość.
4. Przeczytaj logi WAF albo ModSecurity pod kątem konkretnej reguły, która zadziałała, jeśli coś stoi przed aplikacją; fałszywy alarm potrzebuje ograniczonego wyjątku, nie wyłączenia całego zestawu reguł.
5. Potwierdź, że 400 z Twojego API jest zamierzone, zanim zaczniesz je "naprawiać". Wadliwe ciało JSON albo pole, które zawodzi walidację na poziomie składni, powinno zwracać 400; naprawą w takim wypadku są jaśniejsze komunikaty błędów po stronie klienta, nie zmiana kodu statusu.

400 kontra podobne kody

• 401 Unauthorized oznacza, że żądanie zostało dobrze zrozumiane, ale brakuje ważnych poświadczeń albo zostały odrzucone.
• 403 Forbidden oznacza, że żądanie zostało dobrze zrozumiane, ale serwer odmawia jego autoryzacji niezależnie od poświadczeń.
• 404 Not Found oznacza, że żądanie zostało dobrze zrozumiane i żaden zasób nie pasował do ścieżki.
• 413 Payload Too Large to konkretny kod dla treści przekraczającej limit rozmiaru, choć niektóre serwery w praktyce odpowiadają zamiast tego kodem 400.
• 414 URI Too Long to konkretny kod dla linii żądania przekraczającej limit długości.
• 422 Unprocessable Content oznacza, że składnia sparsowała się dobrze, ale semantyka nie, na przykład poprawny JSON z wartością, która zawodzi walidację biznesową - subtelniejsze rozróżnienie, którego większość API nie zawraca sobie głowy robić względem 400.

Jak zapobiec temu, żeby błąd 400 zwalił stronę

400 wprowadzony przez wdrożenie, które zaostrzyło limity nagłówków, albo aktualizację reguły WAF, która zaczyna dopasowywać legalny ruch, nie objawi się jako awaria czy timeout, bo serwer odpowiada natychmiast i poprawnie według własnych zasad. Zaplanowana kontrola HTTP z asercją na oczekiwanym kodzie statusu wyłapuje to w chwili, gdy zaczyna się dziać, zamiast czekać, aż zgłoszenia wsparcia zaczną się piętrzyć. W połączeniu z monitoringiem z wielu lokalizacji mówi też, czy 400 jest powszechne, czy związane z konfiguracją brzegu jednego regionu.

Powiązane błędy

Szerszą rodzinę kodów błędów klienta i serwera opisuje przegląd kodów statusu 4xx. Zobacz też 403 Forbidden dla żądań, które serwer zrozumiał i odrzucił, 404 Not Found dla żądań skierowanych do zasobu, który nie istnieje, oraz 429 Too Many Requests dla żądań odrzuconych z powodu częstotliwości, a nie składni.

Najczęściej zadawane pytania

Dlaczego wyczyszczenie ciasteczek naprawia błąd 400?

Bo ciasteczka jadą jako nagłówki żądania przy każdym żądaniu, a serwer egzekwuje maksymalny łączny rozmiar nagłówków. Lata nagromadzonych ciasteczek albo jedno uszkodzone ciasteczko mogą przepchnąć sumę powyżej tego limitu, a serwer odpowiada 400, zanim przeczyta cokolwiek więcej o żądaniu.

Czy błąd 400 jest taki sam na każdej odwiedzanej witrynie?

Kod i ogólna przyczyna, wadliwa składnia żądania, są wszędzie takie same, ale dokładny limit, który został przekroczony, i dokładne brzmienie strony błędu ustala własna konfiguracja serwera każdej witryny.

Czy moje API powinno zwracać 400 dla nieprawidłowych danych wejściowych?

Tak, gdy dane wejściowe nie dają się sparsować albo brakuje pola sprawdzanego przez API na poziomie składni. To 400 działające zgodnie z zamierzeniem, nie błąd do naprawienia przez rozluźnienie walidacji.

Czy WAF może spowodować błąd 400 przy żądaniu, które wygląda zupełnie normalnie?

Tak. Reguła WAF może oflagować wzorzec w URL, nagłówku albo treści, który jest technicznie poprawnym HTTP, ale pasuje do sygnatury obronnej, a niektóre konfiguracje WAF odpowiadają ogólnym 400 zamiast bardziej konkretnej strony blokady.

Jaka jest różnica między 400 a 413?

413 to konkretny kod dla treści żądania przekraczającej skonfigurowany limit rozmiaru. Wiele serwerów używa go poprawnie, ale niektóre odpowiadają zamiast tego kodem 400 przy tym samym warunku zbyt dużej treści, więc nie zakładaj, że sam kod mówi Ci dokładną przyczynę bez sprawdzenia dokumentacji serwera albo logów.