400 Bad Request: co to znamená a jak to opravit

Co znamená 400 Bad Request

RFC 9110 definuje 400 jako serverův způsob, jak říct, že požadavku nešlo porozumět kvůli chybné syntaxi. Klíčové slovo je syntaxe: server nevyhodnocuje, kdo jste, co smíte dělat, ani jestli prostředek existuje. Říká, že samotný požadavek jako bajty na drátě neodpovídá platnému HTTP požadavku. Může jít o řádek požadavku, hlavičky nebo tělo, podle toho, kde parser vzdá.

Jak se chyba projevuje

Prohlížeče vykreslí jakoukoli obyčejnou chybovou stránku, kterou server pro 400 pošle zpátky; neexistuje žádná vyhrazená stránka na úrovni prohlížeče jako u selhání DNS nebo certifikátu, protože spojení se povedlo a odpověď skutečně dorazila. Běžná varianta zní přesně "400 Bad Request - request header or cookie too large", což příčinu pojmenovává rovnou. Z příkazové řádky:

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

Logy serveru jsou tady nejužitečnějším důkazem, protože na rozdíl od selhání TLS handshake požadavek skutečně dorazil až do aplikační vrstvy a zaznamená se, často i s konkrétní hlavičkou nebo řádkem, který se nepodařilo zpracovat.

Co způsobuje 400 Bad Request

Pro návštěvníka, v pořadí, v jakém na ně nejspíš narazí:

• Předimenzované nebo poškozené cookies. Roky nahromaděné cookies pro jednu doménu, nebo cookie poškozená rozšířením prohlížeče či špatným přesměrováním, běžně vyprodukují přesně hlášku "400 Bad Request - request header or cookie too large", jakmile celková velikost hlaviček překročí limit serveru.
• Překlepnutá nebo špatně zakódovaná URL. Chybný znak, nezakódovaná mezera nebo poškozená sekvence procentuálního kódování v adresním řádku nebo vloženém odkazu se může nepodařit zpracovat jako platnou syntaxi.
• Rozšíření prohlížeče upravující požadavky. Blokátory reklam, nástroje na ochranu soukromí a některá rozšíření VPN přepisují hlavičky nebo řádek požadavku, a chyba v jednom z nich může serveru předat něco poškozeného.
• Cachované přesměrování mířící na rozbitou URL. Prohlížeč se řídí zastaralým přesměrováním na URL, která je sama o sobě neplatná, a 400 se objeví na cíli, ne na odkazu, na který jste skutečně klikli.
• Nahrávaný soubor větší, než server povoluje. Některé konfigurace serveru odpoví na příliš velké nahrání kódem 400 místo specifičtějšího 413 Payload Too Large.

Pro provozovatele webu, přibližně v pořadí, co zkontrolovat nejdřív:

• Limity velikosti hlaviček nebo cookies nastavené příliš nízko na to, co aplikace skutečně posílá, zvlášť po přidání sledovacích cookies, JWT v hlavičkách nebo mechanismu relace, který postupem času roste.
• Neplatná nebo chybějící hlavička Host, kterou může vyprodukovat reverzní proxy nebo špatně nastavený klient, a kterou většina serverů potřebuje, aby požadavek vůbec směrovala.
• Content-Length, který neodpovídá skutečně poslanému tělu, což může způsobit rozbitý klient nebo chybová proxy uprostřed cesty.
• Pravidla web application firewallu nebo ModSecurity odmítající požadavek, jehož syntaxe vypadá člověku v pořádku, ale odpovídá vzoru, který WAF vyhodnotí jako poškozený.
• API záměrně odmítá poškozený JSON kódem 400. Tohle je správné chování, ne chyba: tělo požadavku, které se nepodaří zpracovat jako platný JSON, nebo mu chybí povinné pole, které API ověřuje na úrovni syntaxe, má podle návrhu vracet 400.

Jak zjistit, čí je to chyba

Zopakujte stejný požadavek z čistého prostředí: okno anonymního prohlížení bez rozšíření a bez nahromaděných cookies, nebo obyčejné volání curl na stejnou URL. Pokud čistý požadavek uspěje, příčina byla lokální, nejčastěji cookies nebo rozšíření. Pokud selže stejně z čistého klienta i odjinud, odmítají legitimně sestavený požadavek vlastní limity nebo pravidla serveru, a nejrychlejší způsob, jak to potvrdit ve velkém, je spustit HTTP kontrolu z několika míst najednou a porovnat stavový kód, který každé z nich dostane zpátky.

Jak opravit 400 Bad Request

Pokud jste návštěvník

1. Nejdřív vymažte cookies pro daný web, protože předimenzované nebo poškozené cookies jsou zdaleka nejčastější příčinou. Většina prohlížečů umožňuje vymazat cookies pro jeden web, aniž byste smazali přihlášení všude jinde.
2. Zkuste to znovu v anonymním okně. Čisté okno nemá nahromaděné cookies a podle prohlížeče má obvykle ve výchozím stavu vypnutá i většina rozšíření, což izoluje obě běžné příčiny naráz.
3. Zkontrolujte URL kvůli překlepům nebo cizím znakům, zvlášť po vložení odkazu odněkud, kde mohly přibýt sledovací parametry nebo se poškodit kódování.
4. Vypínejte rozšíření jedno po druhém, pokud chyba přetrvává v běžném okně, ale ne v anonymním, abyste našli, které z nich požadavek přepisuje.
5. Zkuste jiné zařízení nebo síť, abyste vyloučili captive portál nebo lokální proxy, které s webem vůbec nesouvisí.

Pokud web provozujete

1. Zvyšte limity hlaviček a bufferů, pokud je aplikace opravdu potřebuje větší. Na nginx:

   large_client_header_buffers 4 16k;

   Na Apache:

   LimitRequestFieldSize 16384

   Na IIS zkontrolujte jak maxRequestLength v web.config pro tělo požadavku, tak nastavení registru HTTP.sys MaxFieldLength pro jednotlivá pole hlaviček.
2. Omezte, co v cookies a hlavičkách skutečně posíláte, místo abyste jen zvyšovali strop. Ořezání zastaralých cookies, přesun velkých tokenů mimo hlavičky a nastavení kratší životnosti cookies zabrání tomu, aby se problém s růstem používání opakoval.
3. Zkontrolujte zpracování hlavičky Host na reverzní proxy nebo load balanceru a ověřte, že do aplikace předává platnou, očekávanou hodnotu.
4. Přečtěte si logy WAF nebo ModSecurity ohledně konkrétního pravidla, které zafungovalo, pokud je před aplikací nějaké nasazené; falešně pozitivní výsledek potřebuje cílenou výjimku, ne vypnutou celou sadu pravidel.
5. Ověřte, že je 400 z vašeho API záměrné, než ho začnete "opravovat". Poškozené tělo JSON nebo pole, které selže při validaci na úrovni syntaxe, má vracet 400; oprava v tomto případě znamená jasnější chybové zprávy na straně klienta, ne změnu stavového kódu.

400 v porovnání s podobnými kódy

• 401 Unauthorized znamená, že požadavku bylo v pořádku porozuměno, ale chybí platné přihlašovací údaje nebo byly odmítnuty.
• 403 Forbidden znamená, že požadavku bylo v pořádku porozuměno, ale server ho odmítá autorizovat bez ohledu na přihlašovací údaje.
• 404 Not Found znamená, že požadavku bylo v pořádku porozuměno a žádný prostředek dané cestě neodpovídal.
• 413 Payload Too Large je specifický kód pro tělo, které překračuje limit velikosti, i když některé servery v praxi odpovídají místo něj 400.
• 414 URI Too Long je specifický kód pro řádek požadavku, který překračuje limit délky.
• 422 Unprocessable Content znamená, že syntaxe se zpracovala v pořádku, ale sémantika ne, například platný JSON s hodnotou, která selže při obchodní validaci - jemnější rozdíl, který většina API od 400 ani neřeší.

Jak zabránit tomu, aby chyba 400 shodila stránku

400 zavedená nasazením, které zpřísnilo limity hlaviček, nebo aktualizací pravidla WAF, která začne zachytávat legitimní provoz, se neprojeví jako pád nebo timeout, protože server odpovídá okamžitě a podle vlastních pravidel správně. Naplánovaná HTTP kontrola s ověřením očekávaného stavového kódu to zachytí ve chvíli, kdy to začne, místo aby se čekalo, až se nahromadí tikety podpory. V kombinaci s monitoringem z více míst vám navíc řekne, jestli je 400 univerzální, nebo vázaná na konfiguraci edge jednoho regionu.

Související chyby

Širší rodina chybových kódů klienta a serveru je popsaná v přehledu stavových kódů 4xx. Podívejte se také na 403 Forbidden pro požadavky, kterým server porozuměl a odmítl je, 404 Not Found pro požadavky mířící na prostředek, který neexistuje, a 429 Too Many Requests pro požadavky odmítnuté kvůli četnosti, ne kvůli syntaxi.

Často kladené otázky

Proč vymazání cookies opraví chybu 400?

Protože cookies jezdí s každým požadavkem jako hlavičky a server vynucuje maximální celkovou velikost hlaviček. Roky nahromaděných cookies, nebo jedna poškozená cookie, mohou posunout celkový součet za tento limit, a server odpoví 400 dřív, než si o požadavku přečte cokoli dalšího.

Je chyba 400 na každém webu, který navštívím, stejná?

Kód a obecná příčina, poškozená syntaxe požadavku, jsou všude stejné, ale konkrétní limit, který byl překročen, a přesné znění chybové stránky určuje vlastní konfigurace serveru každého webu.

Má moje API vracet 400 pro neplatný vstup?

Ano, pokud se vstup nepodaří zpracovat nebo mu chybí pole, které API ověřuje na úrovni syntaxe. To je 400 fungující přesně podle záměru, ne chyba, kterou by se mělo opravit uvolněním validace.

Může WAF způsobit chybu 400 na požadavku, který vypadá naprosto normálně?

Ano. Pravidlo WAF může označit vzor v URL, hlavičce nebo těle, který je technicky platné HTTP, ale odpovídá obranné signatuře, a některé konfigurace WAF odpoví obecnou 400 místo konkrétnější blokovací stránky.

Jaký je rozdíl mezi 400 a 413?

413 je specifický kód pro tělo požadavku, které překračuje nastavený limit velikosti. Mnoho serverů ho používá správně, ale některé pro stejnou podmínku předimenzovaného těla odpoví místo něj 400, takže z kódu samotného nepředpokládejte přesnou příčinu bez ověření vlastní dokumentace nebo logů serveru.