HTTP 400: De uitgebreide gids over Bad Request en hoe je dit effectief oplost

Een HTTP 400-fout is een van de meest frustrerende foutmeldingen voor zowel gebruikers als ontwikkelaars. Het duidt op een fout in de aanvraag die door de client is verzonden en die de server niet correct kan verwerken. In dit artikel verkennen we wat HTTP 400 precies betekent, welke oorzaken er zijn, hoe je dit zelf kunt debuggen en welke best practices handig zijn om toekomstige problemen te voorkomen. Of je nu een beginner bent die net leert hoe het web werkt of een doorgewinterde developer die betrouwbare API’s bouwt, deze gids biedt duidelijke uitleg, praktische stappen en concrete voorbeelden.

Wat betekent HTTP 400?

HTTP 400 Bad Request is een cliëntfoutstatuscode die aangeeft dat de server de aanvraag niet kan begrijpen vanwege onjuiste syntaxis of onvolledige gegevens. In essentie zegt de server: “De door jou verzonden vraag klopt niet genoeg om te verwerken.” De fout ontstaat meestal door een fout in de query-string, de headers, de payload (bijvoorbeeld JSON of formulierdata) of door incorrecte encoding. Het is dus geen fout aan de kant van de server zelf, maar een signaal dat de client daarin moet verbeteren voordat de server een geldige reactie kan geven.

In de notatie van fetch- en HTTP-verzoeken wordt vaak onderscheid gemaakt tussen een HTTP 400 aan de clientkant en serverfouten (500-range). De 400-range is bedoeld om valide input te handhaven en om te voorkomen dat onvolledige of misvormde data door de applicatielaag heen sijpelt. Een goed geconfigureerde API geeft bij een HTTP 400-fout meestal een korte, duidelijke foutmelding terug die uitlegt wat er mis is, zodat de client dit kan corrigeren.

Oorzaken van HTTP 400 fouten

Er zijn diverse oorzaken voor een HTTP 400-fout. Hieronder vind je de meest voorkomende scenario’s, onderverdeeld naar wat meestal aan de clientzijde ligt of wat bij de server-configuratie kan spelen.

Verkeerde URL-syntaxis

Een fout in de URL, zoals ongeldige tekens, onvolledige paden of een foutief schema, kan direct leiden tot een HTTP 400. Voorbeelden zijn ongeldige percent-encoding of onjuist gebruik van speciale tekens in de URL. Controleer altijd of de URL correct is opgebouwd en of speciale tekens correct zijn gecodeerd.

Onjuiste query-string encoding

Query-parameters moeten correct worden gecodeerd. Een onjuist ge-encodeerde parameter kan de server verwarren en een HTTP 400-fout triggeren. Let op ampersands, gelijke tekens en het correct percentage-encode van alle niet-ASCII-tekens.

Verkeerde headerwaarden

Veel servers vereisen specifieke headers, zoals Content-Type, Accept of Authorization. Een ontbrekende of ongeldige header kan leiden tot een HTTP 400-fout. Ook onjuiste waardes in headers (bijv. een foutief geformatteerde Authorization-header) kunnen oorzaak zijn.

Grote of onaangekomen payload

Wanneer de payload te groot is of niet overeenkomt met de verwachte structuur, kan de server met HTTP 400 reageren. Dit komt vaak voor bij POST- of PUT-verzoeken waar JSON- of form-gegevens ontbreken of incorrect geformatteerd zijn.

Onverwachte of beschadigde cookies

Cookies die beschadigd of ongeldig zijn, kunnen HTTP 400-fouten veroorzaken, vooral bij applicaties die afhankelijk zijn van cookies voor sessies of authenticatie. Als een client regelmatig cookies ontvangt die niet correct zijn, kan dit leiden tot herhaalde 400-fouten.

Ongeldige of ontbrekende payload-indeling

Bij veel APIs is de payload afhankelijk van een correct gedefinieerde Content-Type (bijv. application/json, application/x-www-form-urlencoded). Als de server de payload niet kan ontleden volgens het verwachte formaat, verschijnt vaak HTTP 400 Bad Request.

Verkeerde of ontbrekende veldvalidatie

Inputvalidatie aan de serverkant kan foutieve of ontbrekende velden detecteren en een HTTP 400 teruggeven met details over wat ontbreekt of ongeldig is. Dit is een veelvoorkomende oorzaak bij API’s die streng valideren op veldniveau.

Proxies, load balancers en beveiligingsfilters

Een tussenliggende laag zoals een reverse proxy of een WAF (Web Application Firewall) kan aanvragen als ongeldige structureren beschouwen en een HTTP 400 teruggeven. Dit kan gebeuren als een header te lang is, als de request te groot is, of als bepaalde patronen overeenkomen met beveiligingsregels.

Hoe HTTP 400 op te lossen aan de client-kant

Wanneer je een HTTP 400-fout tegenkomt, is de eerste stap vaak om grondig te controleren wat er in de aanvraag zit en hoe de server die aanvraag verwerkt. Hieronder staan praktische stappen die je direct kunt toepassen.

Controleer de URL en encoding

Begin met de URL die je verzendt. Controleer op onjuiste tekens, onvolledige paden en foutieve encoding. Gebruik percent-encoding waar nodig en zorg ervoor dat de scheidingen tussen pad- en query-string correct zijn. Test met eenvoudige, minimale URL’s om te zien of de fout blijft optreden.

Inspecteer headers en authenticatie

Bekijk alle verzonden headers. Controleer of Content-Type en Accept correct zijn ingesteld voor jouw payload. Als authenticatie vereist is, verifieer dan de geldigheid van tokens of cookies en zorg ervoor dat ze niet verlopen zijn. Soms volstaat het opnieuw inloggen of een nieuw token genereren.

Controleer payload en formaat

Als je een POST- of PUT-verzoek doet, kijk dan naar de payload. Controleer de structuur van JSON of formulierdata, valideer velden en zorg ervoor dat de inhoud overeenkomt met wat de API verwacht. Gebruik schema’s of JSON-validators waar mogelijk.

Verwijder of reset cookies

Cookies kunnen de oorzaak zijn van een HTTP 400-fout. Verwijder de relevante cookies in de browser of reset cookies via je applicatie, vooral als cookies sessienciaal zijn. Controleer vervolgens of het probleem zich nog steeds voordoet.

Test met minimale voorbeeldverzoeken

Herhaal de aanvraag met een minimale set aan parameters. Als het minimale voorbeeld werkt, kun je geleidelijk extra velden toevoegen om te bepalen welke parameter de fout veroorzaakt.

Gebruik robuuste foutmeldingen

Wanneer jouw client of API duidelijke foutmeldingen retourneert, kun je sneller achterhalen wat er mis is. Vermijd te vage berichten zoals “Bad Request” en geef concrete details zoals welke parameter mist of onjuist is geformatteerd.

Serverzijde debugging van HTTP 400

Als http 400 aan de server toe te schrijven is, verleg je focus naar serverlogs en validatiepunten in de applicatielogica. Hieronder staan best practices om HTTP 400 effectief te debuggen.

Logboeken en middleware controleren

Bekijk serverlogboeken voor de exacte foutmelding en de context van de aanvraag. Gebruik structured logging voor betere zoekbaarheid. Controleer ook any middleware die inkomende verzoeken wijzt, zoals API-gateways, proxy-servers of load balancers, omdat daar vaak de eerste 400-regels verschijnen.

Inputvalidatie en schema’s

Beoordeel waar en hoe inputs worden gevalideerd. Gebruik duidelijke schema’s (bijv. JSON-schema, OpenAPI-spec) en valideer op de serverzijde koper end-to-end. Controleer ook op mogelijke edge-cases zoals lege strings, nulwaarden of onverwachte tekens.

Decode- en encodingpraktijken

Zorg dat URL-decode en payload-decoding consistent zijn. Fouten in decode-logica leiden vaak tot onbegrijpelijke fouten die als HTTP 400 kunnen verschijnen. Houd rekening met verschillende encodings en karaktersets.

Beperkingen en configuratie van proxies

Controleer of er proxies of firewalls tussen client en server staan. Soms blokkeren of wijzigen deze tussenlagen bepaalde verzoeken, wat resulteert in 400-fouten. Pas configuraties aan en test direct op de origin server om proxy-gerelateerde oorzaken uit te sluiten.

Beveiligingsfilters en validatie-regels

WAF-regels of beveiligingsfilters kunnen legitieme verzoeken onterecht blokkeren. Controleer hun logboeken en pas regels aan als nodig. Zorg ervoor dat beveiligingscontroles niet te streng zijn voor normale inputs.

Specifieke voorbeelden en best practices

Om een beter begrip te krijgen van hoe HTTP 400 eruitziet in real-world scenario’s, geven we enkele concrete voorbeelden en bijbehorende oplossingen. Door deze voorbeelden te bestuderen, kun je sneller herkennen wat er mis kan zijn en hoe je het effectief oplost.

Voorbeeld 1: ongeldige JSON payload

Een API verwacht JSON-gegevens met een veld “email”. Als de payload ongeldig is, bijvoorbeeld door ontbrekende aanhalingstekens of een ontbrekend veld, kan de server HTTP 400 retourneren. Oplossing: valideer JSON aan de clientkant voordat je verzendt en voeg duidelijke foutmeldingen toe aan de respons.

curl -X POST https://api.example.com/register
  -H "Content-Type: application/json"
  -d '{"email": "[email protected]", "name": "Jan"}'

Voorbeeld 2: ontbrekende vereiste query-parameter

Wanneer een endpoint een paramater nodig heeft, bijvoorbeeld “userId”, en deze ontbreekt of leeg is, geeft de server vaak HTTP 400. Oplossing: zorg dat essentiële parameters altijd aanwezig zijn of geef duidelijke foutcodes terug aan de client.

GET /api/profile?userId= 

Voorbeeld 3: te lange header

Sommige servers hebben een limiet voor de lengte van headers. Een request die te veel cookies bevat of lange custom headers kan HTTP 400 genereren. Oplossing: minimaliseer headers, split cookies waar mogelijk en gebruik stateless sessies waar handig.

Voorbeeld 4: ongeldige Content-Type

Als een client een onbekende of onverwachte Content-Type verzendt, kan een server dit afwijzen met HTTP 400. Oplossing: pas de Content-Type aan aan wat de API verwacht, zoals application/json of application/x-www-form-urlencoded.

Best practices voor ontwerp en API-architectuur

Een doordachte aanpak voorkomt veel HTTP 400-fouten. Hieronder enkele aanbevelingen die je kunt toepassen bij het ontwerpen van API’s en webdiensten.

• Definieer duidelijke API-schemas en contracten met OpenAPI of JSON-schema. Dit maakt validatie zowel aan client- als serverzijde eenvoudiger en consistent.
• Gebruik duidelijke foutberichten met specifieke codes en beschrijvingen. Vermijd generieke meldingen; geef concrete aanwijzingen over wat ontbreekt of fout is gegaan.
• Leer de grenzen van inputdata kennen en valideer vroeg in de stapel. Early validation reduceert latere fouten en verbetert de responscapaciteit.
• Beperk de grootte van payloads en headers. Stel realistische limieten in en geef passende foutcodes terug als een request deze limieten overschrijdt.
• Distributeer error handling tussen client en server. Laat de client handling leveren zodat gebruikersvriendelijke feedback krijgen, terwijl de server robuuste validatie uitvoert.
• Vermijd het verzenden van gevoelige informatie in foutberichten. Laat eventuele technische details achter in logs en geef beveiligde, begrijpelijke feedback terug aan eindgebruikers.
• Test onder realistische omstandigheden: fuzzing, boundary testing en API-contract tests helpen om HTTP 400-problemen vroegtijdig op te sporen.

Beste praktijken voor debugging en monitoring

Naast directe debugging is het verstandig om een structurele aanpak te hebben voor monitoring en continue verbetering. Hier zijn enkele tips die je kunt toepassen in jouw omgeving.

• Implementeer end-to-end logging die de inkomende aanvraag, headers, payload en de foutmelding vastlegt. Gebruik correlatie-id’s om logs over meerdere systemen te kunnen samenvoegen.
• Houd statistieken bij: aantal HTTP 400-fouten per endpoint en per gebruiker. Dit maakt trends zichtbaar en geeft aan waar verbetering nodig is.
• Gebruik rate-limiting en input-validatie als guardrails. Dit voorkomt dat brute-forcing of misbruik leidt tot fouten die gebruikerservaring schaden.
• Implementeer automatische regressietests die 400-scenario’s afdekken. Zorg dat bij elke deploy regressies snel worden opgespoord.
• Documenteer de verwachte inputs per endpoint. Een goed gedocumenteerde API vermindert onduidelijkheden en fouten aanzienlijk.

Veelgestelde vragen over HTTP 400

Hier volgen korte antwoorden op vaak gestelde vragen over HTTP 400 bad request.

Is HTTP 400 altijd een fout aan de client?

Meestal wel. Een HTTP 400 geeft aan dat de aanvraag niet voldoet aan de vereisten die de server heeft gesteld. In sommige gevallen kan een tussenlaag, zoals een proxy, de oorzaak zijn, maar uiteindelijk is de client verantwoordelijk voor het verzenden van correcte en valide verzoeken.

Hoe verschilt HTTP 400 van 422?

HTTP 400 Bad Request duidt op een algemene fout in de request-syntaxis of parametervalidatie. HTTP 422 Unprocessable Entity wordt vaak gebruikt wanneer de syntaxis correct is maar de inhoud invalid is, bijvoorbeeld wanneer een veld al dan niet voldoet aan bedrijfsregels, zoals een email die geen geldig formaat heeft maar syntactisch correct is.

Kan een 400 fout voorkomen bij GET-verzoeken?

Ja. Ook GET-verzoeken kunnen een HTTP 400 opleveren als de query-string onjuist is geformatteerd of verplichte parameters ontbreken.

Moet een API altijd HTTP 400 teruggeven voor invalid input?

Het hangt af van de ontwerprichtlijnen en het type input. Veel API’s geven HTTP 400 voor ontoereikende syntaxis en ontbrekende/ongeldige parameters. Voor gespecialiseerde validatie kan HTTP 422 of een aangepaste foutcode gepast zijn. Het belangrijkste is consequente discipline in foutafhandeling.

Conclusie

HTTP 400 Bad Request is een cruciale foutcode die aantoont dat de client een aanvraag heeft verzonden die de server niet kan verwerken. Het kan ontstaan door onjuiste URL-syntaxis, foutieve headers, ongeldig of ontbrekend payload, of tussenlagen zoals proxies en firewalls. Door systematisch te controleren, te valideren en duidelijke foutmeldingen te geven, kun je HTTP 400-problemen effectief oplossen en voorkomen. Een goed ontworpen API, samen met robuuste validatie en heldere communicatie tussen client en server, zorgt ervoor dat toekomstige 400-fouten minder vaak voorkomen en beter afhandeld worden. Met de juiste aanpak, tooling en tests verhoog je de betrouwbaarheid van jouw webapplicaties en APIs aanzienlijk.