Wysyłasz formularz albo otwierasz stronę, a zamiast treści widzisz „400 Bad Request”. Najczęściej serwer odrzuca wtedy żądanie jako nieprawidłowe, choć przyczyna może leżeć w zapisanym w przeglądarce pliku cookie, danych formularza albo konfiguracji aplikacji.
Najpierw ustal, gdzie powstaje odpowiedź 400
- Jedna strona: sprawdź jej pliki cookie i adres URL.
- Własne API: odczytaj treść odpowiedzi i zweryfikuj format danych.
- ASP.NET Core: atrybut [ApiController] może zwrócić 400 przed uruchomieniem metody kontrolera.
- Wiele aplikacji za proxy: sprawdź logi serwera i bramy, bo kod mógł powstać przed dotarciem żądania do aplikacji.
400 opisuje odrzucone żądanie, a nie winę użytkownika
Na ekranie wszystko może wyglądać zwyczajnie: poprawny adres, działające logowanie, formularz bez widocznych błędów. Mimo to serwer uznaje, że nie może obsłużyć otrzymanego żądania. Kod 400 sam nie wskazuje, który jego element zawiódł.
RFC 9110 opisuje 400 jako odpowiedź dla żądania, którego serwer nie może lub nie chce przetworzyć z powodu problemu przypisanego stronie klienta, na przykład błędnej składni albo nieprawidłowego opakowania wiadomości. „Strona klienta” oznacza tu stronę wysyłającą żądanie, a może nią być przeglądarka, skrypt, aplikacja mobilna lub inne API. W interpretacji logów rozdzielam więc miejsce wykrycia błędu od osoby, która go spowodowała.
Przeglądarka może wysłać nieaktualne cookie, ale równie dobrze aplikacja może źle zbudować JSON albo pośredniczący serwer może odrzucić nagłówek. Ten sam numer nie oznacza zatem jednej uniwersalnej naprawy.
Podobne komunikaty mogą oznaczać inny problem niż 400
„Błąd żądania” brzmi jak ogólna etykieta, ale sąsiednie statusy HTTP pozwalają zawęzić diagnozę. Warto odczytać dokładny kod, zwłaszcza gdy komunikat pochodzi z API lub własnej aplikacji.
RFC 9110 rozróżnia między innymi 400, 413 i 422. W uproszczeniu: pierwszy dotyczy żądania uznanego za nieprawidłowe, drugi zbyt dużej treści, a trzeci poprawnie sformułowanej treści, której nie da się przetworzyć ze względu na jej znaczenie. Dla programisty ta różnica podpowiada, czy zacząć od składni i nagłówków, limitu rozmiaru, czy walidacji danych.
| Kod | Typowy sygnał | Pierwszy kierunek sprawdzenia |
|---|---|---|
| 400 | Żądanie lub jego część zostały odrzucone jako nieprawidłowe | Adres, nagłówki, cookie, format i wymagane pola |
| 413 | Treść żądania przekracza limit | Rozmiar wysyłanego pliku lub ograniczenia serwera |
| 422 | Treść ma poprawną składnię, ale nie spełnia warunków przetworzenia | Znaczenie i spójność przekazanych danych |
Nie każda aplikacja stosuje te kody w identyczny sposób, a brama sieciowa może zastąpić odpowiedź własną. Dlatego kod to wskazówka, a treść odpowiedzi i logi często mówią więcej.
Jeśli błąd dotyczy jednej strony, zacznij od jej cookie
Komunikat „Request Header Or Cookie Too Large” mocno zawęża trop: serwer odrzuca zbyt duży nagłówek, często zawierający cookie tej witryny. Powtarzające się zgłoszenia użytkowników dotyczą sytuacji, w której problem pojawia się na pojedynczej stronie lub po zalogowaniu, a usunięcie danych tej witryny pomaga. Nie trzeba od razu czyścić całej historii przeglądania.
- Otwórz stronę w oknie prywatnym. Jeśli tam działa, problem prawdopodobnie wiąże się z danymi zapisanymi dla zwykłej sesji.
- Usuń cookie i dane witryny, której dotyczy komunikat, a potem zaloguj się ponownie.
- Jeśli błąd pozostaje, sprawdź adres bez parametrów skopiowanych z długiego linku i spróbuj w innej przeglądarce.
Usunięcie cookie wyloguje z danej witryny i może skasować jej lokalne ustawienia. Gdy błąd występuje na wielu stronach albo w różnych przeglądarkach, szukaj przyczyny poza pojedynczym cookie, na przykład w rozszerzeniu, proxy lub aplikacji wysyłającej żądanie.
W ASP.NET Core 400 może pojawić się przed wejściem do kontrolera
Własne API może zwracać 400, choć metoda kontrolera nie została jeszcze wykonana. W ASP.NET Core atrybut [ApiController] uruchamia automatyczną odpowiedź 400, gdy wiązanie lub walidacja modelu zgłosi nieprawidłowy stan. Brak logu z wnętrza metody nie wyklucza więc błędu danych wejściowych.
Microsoft Learn opisuje ten mechanizm przez filtr ModelStateInvalidFilter; domyślna odpowiedź może zawierać szczegóły w formacie ValidationProblemDetails. Przykład: klient wysyła w polu liczbowym tekst „abc”. Konwersja nie powiedzie się, stan modelu będzie nieprawidłowy, a klient otrzyma 400, zanim kod akcji zacznie działać.
Przy takim wyniku porównaj JSON z typami i wymaganymi polami modelu, sprawdź nagłówek Content-Type oraz odczytaj odpowiedź walidacyjną. Jeśli komunikat zbyt ogólny, zaloguj identyfikator żądania i wynik walidacji, ale nie zapisuj haseł ani tokenów. Gdy kontroler nie dostaje żądania w ogóle, zajrzyj do logów serwera HTTP lub proxy.
Trzy pytania prowadzą od komunikatu do przyczyny
Najkrótsza droga do diagnozy zaczyna się od miejsca wystąpienia błędu. Zapisz dokładny komunikat i sprawdź, czy odpowiedź pojawia się na jednej stronie, w jednym wywołaniu API, czy w całej aplikacji.
| Sytuacja | Prawdopodobny trop | Co zrobić |
|---|---|---|
| Błąd tylko na jednej witrynie, działa w oknie prywatnym | Cookie lub lokalne dane witryny | Usuń dane tej domeny i zaloguj się ponownie |
| API zwraca JSON z błędami pól | Nieudane wiązanie lub walidacja modelu | Porównaj treść żądania z modelem i wymaganiami endpointu |
| Komunikat mówi o zbyt dużym nagłówku | Cookie albo inne nagłówki przekraczają limit | Ogranicz dane wysyłane w nagłówkach; sprawdź konfigurację klienta i serwera |
| Własna metoda API nie rejestruje żądania | Odrzucenie przez serwer HTTP, proxy lub filtr walidacji | Sprawdź logi kolejnych warstw i identyfikator żądania |
Jeżeli problem występuje u wielu osób i w różnych przeglądarkach, zgłoś go administratorowi witryny wraz z godziną, adresem endpointu i identyfikatorem żądania, jeśli jest widoczny. Nie przesyłaj publicznie cookie, tokenów ani pełnych nagłówków autoryzacyjnych. Sam status 400 nie wystarcza do diagnozy, ale dokładny komunikat i miejsce, w którym żądanie znika, zwykle pozwalają wskazać następny krok.
