400 Bad Request: wat het betekent en hoe u het oplost

Wat 400 Bad Request betekent

RFC 9110 definieert 400 als de manier waarop de server aangeeft dat het verzoek niet kon worden begrepen vanwege ongeldige syntaxis. Het sleutelwoord is syntaxis: de server beoordeelt niet wie u bent, wat u mag doen of of de resource bestaat. Hij zegt dat het verzoek zelf, als bytes op de lijn, niet parseert als een geldig HTTP-verzoek. Dat kan de requestregel zijn, de headers, of de body, afhankelijk van waar de parser vastloopt.

Hoe de fout verschijnt

Browsers tonen de eenvoudige foutpagina die de server voor een 400 teruggeeft; er is geen aparte browserpagina zoals bij een DNS- of certificaatfout, omdat de verbinding wel tot stand kwam en er een antwoord binnenkwam. Een veelvoorkomende variant leest letterlijk "400 Bad Request - request header or cookie too large", wat de oorzaak direct noemt. Vanaf de commandoregel:

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

Serverlogs zijn hier het nuttigste bewijs, want anders dan bij een mislukte TLS-handshake bereikte het verzoek wel de applicatielaag en wordt het gelogd, vaak met de specifieke header of regel die niet te parseren was.

Wat een 400 Bad Request veroorzaakt

Voor een bezoeker, in de volgorde waarin u ze het vaakst daadwerkelijk tegenkomt:

• Te grote of beschadigde cookies. Jaren opgebouwde cookies voor één domein, of een cookie die is verminkt door een extensie of een foute redirect, leveren stelselmatig precies de melding "400 Bad Request - request header or cookie too large" op zodra de totale headergrootte de limiet van de server overschrijdt.
• Een verkeerd getypte of slecht gecodeerde URL. Een verdwaald teken, een niet-gecodeerde spatie, of een gebroken percent-encoding-reeks in de adresbalk of een geplakte link kan niet als geldige syntaxis parseren.
• Een browserextensie die verzoeken aanpast. Adblockers, privacytools en sommige VPN-extensies herschrijven headers of de requestregel, en een bug in een van hen kan de server iets misvormds opleveren.
• Een gecachete redirect die naar een kapotte URL wijst. De browser volgt een verouderde redirect naar een URL die zelf ongeldig is, en de 400 verschijnt op de bestemming, niet op de link waarop u daadwerkelijk klikte.
• Een bestandsupload groter dan de server toestaat. Sommige serverconfiguraties beantwoorden een te grote upload met 400 in plaats van de specifiekere 413 Payload Too Large.

Voor de sitebeheerder, ruwweg in de volgorde die het eerst de moeite waard is om te controleren:

• Header- of cookiegroottelimieten die te laag zijn ingesteld voor wat de applicatie daadwerkelijk verstuurt, vooral na het toevoegen van trackingcookies, JWT's in headers, of een sessiemechanisme dat na verloop van tijd groeit.
• Een ongeldige of ontbrekende Host-header, die een reverse proxy of een verkeerd geconfigureerde client kan veroorzaken, en die de meeste servers nodig hebben om het verzoek überhaupt te routeren.
• Een Content-Length die niet overeenkomt met de daadwerkelijk verstuurde body, wat een kapotte client of een gebrekkige proxy ertussenin kan veroorzaken.
• Regels van een web application firewall of ModSecurity die een verzoek afwijzen waarvan de syntaxis er voor een mens prima uitziet maar dat overeenkomt met een defensief patroon dat de WAF als misvormd behandelt.
• Een API die opzettelijk misvormde JSON afwijst met 400. Dit is correct gedrag, geen bug: een requestbody die niet als geldige JSON parseert, of een verplicht veld mist dat de API op syntaxisniveau valideert, hoort per ontwerp 400 terug te geven.

Hoe u vaststelt wiens fout het is

Reproduceer hetzelfde verzoek vanuit een schone omgeving: een privévenster zonder extensies en zonder opgebouwde cookies, of een eenvoudige curl-aanroep naar dezelfde URL. Slaagt het schone verzoek wel, dan lag de oorzaak lokaal, meestal cookies of een extensie. Faalt het identiek vanuit een schone client én vanaf een heel andere plek, dan wijzen de eigen limieten of regels van de server een legitiem gevormd verzoek af, en de snelste manier om dat op schaal te bevestigen is een HTTP-controle uit te voeren vanaf meerdere locaties tegelijk en de statuscodes te vergelijken die elk teruggeeft.

Hoe u een 400 Bad Request oplost

Bent u de bezoeker

1. Wis eerst de cookies voor de site, want te grote of beschadigde cookies zijn verreweg de meest voorkomende oorzaak. De meeste browsers laten u cookies voor één site wissen zonder alle andere sessies te verwijderen.
2. Probeer het opnieuw in een privévenster. Een schoon venster heeft geen opgebouwde cookies en schakelt, afhankelijk van de browser, de meeste extensies standaard uit, wat beide veelvoorkomende oorzaken tegelijk uitsluit.
3. Controleer de URL op typefouten of verdwaalde tekens, vooral na het plakken van een link vanaf een plek die mogelijk trackingparameters heeft toegevoegd of de codering heeft gebroken.
4. Schakel extensies één voor één uit als de fout aanhoudt in een normaal venster maar niet in een privévenster, om te vinden welke het verzoek herschrijft.
5. Probeer een ander apparaat of netwerk om een captive portal of een lokale proxy uit te sluiten die helemaal niets met de site te maken heeft.

Beheert u de site

1. Verhoog de header- en bufferlimieten als de applicatie ze echt groter nodig heeft. Op nginx:

   large_client_header_buffers 4 16k;

   Op Apache:

   LimitRequestFieldSize 16384

   Op IIS controleert u zowel maxRequestLength in web.config voor de requestbody als de HTTP.sys-registerinstelling MaxFieldLength voor individuele headervelden.
2. Verminder wat u daadwerkelijk in cookies en headers verstuurt in plaats van alleen het plafond te verhogen. Verouderde cookies opruimen, grote tokens uit headers halen en kortere cookielevensduren instellen voorkomt dat het probleem terugkeert naarmate het gebruik groeit.
3. Controleer de afhandeling van de Host-header bij de reverse proxy of loadbalancer, en bevestig dat die een geldige, verwachte waarde doorstuurt naar de applicatie.
4. Lees de WAF- of ModSecurity-logs voor de specifieke regel die afging, als er een voor de applicatie staat; een vals positief daar vraagt om een gerichte uitzondering, niet om het uitschakelen van de hele regelset.
5. Bevestig dat een 400 van uw eigen API opzettelijk is voordat u het "oplost". Een misvormde JSON-body of een veld dat op syntaxisniveau faalt bij validatie hoort 400 terug te geven; de oplossing is dan duidelijkere foutmeldingen aan de kant van de client, niet het wijzigen van de statuscode.

400 versus vergelijkbare codes

• 401 Unauthorized betekent dat het verzoek prima werd begrepen, maar dat geldige inloggegevens ontbreken of werden geweigerd.
• 403 Forbidden betekent dat het verzoek prima werd begrepen, maar dat de server weigert het te autoriseren, ongeacht de inloggegevens.
• 404 Not Found betekent dat het verzoek prima werd begrepen en dat geen enkele resource overeenkwam met het pad.
• 413 Payload Too Large is de specifieke code voor een body die een groottelimiet overschrijdt, al beantwoorden sommige servers dit in de praktijk toch met 400.
• 414 URI Too Long is de specifieke code voor een requestregel die een lengtelimiet overschrijdt.
• 422 Unprocessable Content betekent dat de syntaxis prima parseerde maar de semantiek niet, bijvoorbeeld geldige JSON met een waarde die faalt bij bedrijfsvalidatie, een fijner onderscheid dan de meeste API's de moeite waard vinden om los te maken van 400.

Hoe u voorkomt dat een 400-fout een pagina platlegt

Een 400 die wordt geïntroduceerd door een deployment die headerlimieten heeft aangescherpt, of een WAF-regelupdate die legitiem verkeer begint te matchen, verschijnt niet als een crash of een timeout, want de server antwoordt direct en correct volgens zijn eigen regels. Een geplande HTTP-controle met een assertie op de verwachte statuscode vangt dat op het moment dat het begint te gebeuren, in plaats van te wachten tot de supporttickets zich opstapelen. In combinatie met monitoring vanaf meerdere locaties laat het u ook zien of de 400 overal optreedt of gebonden is aan de edge-configuratie van één regio.

Gerelateerde fouten

De bredere familie van client- en serverfoutcodes wordt behandeld in het 4xx-overzicht. Zie ook 403 Forbidden voor verzoeken die de server begreep en weigerde, 404 Not Found voor verzoeken gericht op een resource die niet bestaat, en 429 Too Many Requests voor verzoeken die worden geweigerd vanwege volume in plaats van syntaxis.

Veelgestelde vragen

Waarom lost het wissen van cookies een 400-fout op?

Omdat cookies bij elk verzoek meeliften als requestheaders, en een server een maximale totale headergrootte handhaaft. Jaren opgebouwde cookies, of één beschadigde cookie, kunnen het totaal over die limiet duwen, en de server antwoordt dan 400 voordat hij iets anders over het verzoek leest.

Is een 400-fout op elke website die ik bezoek hetzelfde?

De code en de algemene oorzaak, misvormde requestsyntaxis, zijn overal hetzelfde, maar de exacte limiet die werd overschreden en de exacte tekst van de foutpagina worden bepaald door de eigen serverconfiguratie van elke site.

Moet mijn API 400 teruggeven bij ongeldige invoer?

Ja, wanneer de invoer niet te parseren is of een veld mist dat de API op syntaxisniveau controleert. Dat is 400 zoals bedoeld, geen bug die u oplost door de validatie te versoepelen.

Kan een WAF een 400-fout veroorzaken bij een verzoek dat er volledig normaal uitziet?

Ja. Een WAF-regel kan een patroon in een URL, header of body markeren dat technisch geldige HTTP is maar overeenkomt met een defensieve signatuur, en sommige WAF-configuraties antwoorden met een generieke 400 in plaats van een specifiekere blokkeerpagina.

Wat is het verschil tussen 400 en 413?

413 is de specifieke code voor een requestbody die een geconfigureerde groottelimiet overschrijdt. Veel servers gebruiken die correct, maar sommige antwoorden in plaats daarvan met 400 bij dezelfde te-grote-body-conditie, dus ga niet ervan uit dat de code alleen u de exacte oorzaak vertelt zonder de eigen documentatie of logs van de server te controleren.