PK Systems PK Systems
Web & marketing

HTTP-statuscode-referentie

Zoek en leer de betekenis, typische oorzaak en use case van elke gangbare HTTP-statuscode, met cURL-/Python-/JS-/PHP-snippets.

HTTP-statuscode-referentie

100 Continue #

Een tussenresponse die signaleert dat de server de verzoek-headers heeft ontvangen en de client de body kan gaan verzenden. Gedefinieerd in RFC 9110 sectie 15.2.1.

Veelvoorkomende oorzaak

De client heeft een Expect: 100-continue-header gestuurd om te testen of de server een grote body zal accepteren voordat hij die verzendt.

Wanneer gebruiken

Gebruikt tussen de headers en de body van lange uploads (PUT, POST), zodat de client geen bandbreedte verspilt aan een verzoek dat de server zou afwijzen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 100 Continue
101 Switching Protocols #

De server stemt ermee in om over te schakelen op een ander applicatieprotocol op dezelfde TCP-verbinding, zoals vermeld in de Upgrade-header. RFC 9110 §15.2.2.

Veelvoorkomende oorzaak

De client heeft een Upgrade aangevraagd (meestal naar WebSocket of HTTP/2 over h2c) en de server heeft die geaccepteerd.

Wanneer gebruiken

WebSocket-handshakes zijn vandaag de dag het dominante gebruik. Na 101 is de verbinding geen HTTP meer.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 101 Switching Protocols
200 OK #

Standaard succesresponse — het verzoek is gelukt en de response-body bevat de gevraagde representatie. RFC 9110 §15.3.1.

Veelvoorkomende oorzaak

Het verzoek was geldig, geautoriseerd en zonder redirect afgehandeld.

Wanneer gebruiken

GET's die data teruggeven, POST's/PUT's die inline zijn verwerkt in plaats van asynchroon, gezonde API-responses.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 200 OK
201 Created #

Het verzoek is gelukt en heeft direct geleid tot een nieuwe bron. De Location-header MOET naar de nieuwe bron wijzen. RFC 9110 §15.3.2.

Veelvoorkomende oorzaak

Een POST of PUT heeft een bron aangemaakt (een database-rij, een bestand, een gebruiker, etc.).

Wanneer gebruiken

Gebruik na het aanmaken van REST-bronnen. Geef de nieuwe representatie in de body terug en een Location-header.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 201 Created
202 Accepted #

Het verzoek is geaccepteerd voor verwerking, maar nog niet voltooid. De verwerking kan later slagen of mislukken. RFC 9110 §15.3.3.

Veelvoorkomende oorzaak

Asynchrone verwerking is in de wachtrij gezet. Het werk gebeurt later.

Wanneer gebruiken

Achtergrondtaken, batch-importeindpunten, alles wat een job-status-URL teruggeeft terwijl het werk nog loopt.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 202 Accepted
204 No Content #

Het verzoek is gelukt; de response heeft bewust geen body. Headers kunnen wel metadata bevatten. RFC 9110 §15.3.5.

Veelvoorkomende oorzaak

Een update of delete die geen representatie hoeft terug te geven.

Wanneer gebruiken

DELETE-responses, PUT/PATCH waarbij de client de nieuwe representatie al heeft, save-and-stay-eindpunten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 204 No Content
206 Partial Content #

De server heeft slechts een deel van de representatie teruggegeven als reactie op een Range-verzoek. RFC 9110 §15.3.7.

Veelvoorkomende oorzaak

De client heeft via de Range-header om een byte-bereik gevraagd.

Wanneer gebruiken

Hervatbare downloads, video streamen met seek, en parallelle chunk-downloads.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 206 Partial Content
301 Moved Permanently #

De doelbron heeft een nieuwe permanente URI. Clients ZOUDEN bookmarks moeten bijwerken en zoekmachines werken hun index bij. RFC 9110 §15.4.2.

Veelvoorkomende oorzaak

Een wijziging van de canonical URL — domeinhernoeming, slug-fix, HTTPS-migratie.

Wanneer gebruiken

Langdurige redirects. Vermijd 301 voor kortlopende redirects, omdat clients en tussenliggende systemen agressief cachen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 301 Moved Permanently
302 Found #

De doelbron bevindt zich tijdelijk onder een andere URI. Clients zouden de nieuwe URI moeten opvragen zonder de methode-semantiek te wijzigen, maar historisch herschrijven de meeste POST naar GET. RFC 9110 §15.4.3.

Veelvoorkomende oorzaak

Tijdelijke redirect met eigenaardig methode-herschrijfgedrag, behouden voor compatibiliteit met legacy.

Wanneer gebruiken

Legacy code paths. Geef in nieuwe API's de voorkeur aan 303 of 307 om eenduidig te zijn over methode-afhandeling.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 302 Found
303 See Other #

Verwijst naar een bron die met GET moet worden opgehaald, ongeacht de oorspronkelijke methode. RFC 9110 §15.4.4.

Veelvoorkomende oorzaak

Na een niet-idempotente POST stuurt de server de client naar een bevestigingspagina of een nieuw aangemaakte bron.

Wanneer gebruiken

Post/Redirect/Get-patroon. Herschrijft altijd naar GET, dus veilig na het indienen van een formulier.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 303 See Other
304 Not Modified #

De gecachte representatie die de client al heeft, is nog steeds geldig; er wordt geen body gestuurd. RFC 9110 §15.4.5.

Veelvoorkomende oorzaak

De client heeft If-None-Match of If-Modified-Since gestuurd en de validators kwamen overeen met de huidige bron.

Wanneer gebruiken

Conditionele GET-responses voor caching. Spaart bandbreedte op ongewijzigde statische assets en API-antwoorden.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 304 Not Modified
307 Temporary Redirect #

Zoals 302, maar behoudt de verzoekmethode en body expliciet. RFC 9110 §15.4.8.

Veelvoorkomende oorzaak

Een korte redirect waarbij de oorspronkelijke POST/PUT op de nieuwe URI opnieuw moet worden afgespeeld.

Wanneer gebruiken

Onderhoudsredirects, A/B-routing of geo-redirects die de oorspronkelijke methode moeten behouden.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 307 Temporary Redirect
308 Permanent Redirect #

Zoals 301, maar behoudt de verzoekmethode en body expliciet. RFC 9110 §15.4.9.

Veelvoorkomende oorzaak

Een wijziging van de canonical URI voor niet-GET-methodes (HTTPS-upgrade voor POST-API's, route-hernoemingen).

Wanneer gebruiken

Permanente redirects voor REST-API's. Gebruik dit in plaats van 301 wanneer de oorspronkelijke methode niet mag worden herschreven.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 308 Permanent Redirect
400 Bad Request #

De server kan het verzoek niet verwerken vanwege een clientfout: misvormde syntax, ongeldige framing, misleidende routering. RFC 9110 §15.5.1.

Veelvoorkomende oorzaak

Stukke JSON, ontbrekend verplicht veld, misvormde header, te grote cookie.

Wanneer gebruiken

Algemene fallback voor clientfouten. Geef de voorkeur aan specifiekere codes (422, 411, 415) wanneer die van toepassing zijn.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 400 Bad Request
401 Unauthorized #

Het verzoek mist geldige authenticatiecredentials. De response MOET een WWW-Authenticate-header bevatten met geaccepteerde schema's. RFC 9110 §15.5.2.

Veelvoorkomende oorzaak

Ontbrekend, verlopen of ongeldig token; geen Authorization-header waar er een vereist is.

Wanneer gebruiken

API-eindpunten achter authenticatie. Onderscheidt zich van 403 — 401 is "niet geauthenticeerd", 403 is "geauthenticeerd maar niet toegestaan".

curl -i -X HEAD https://example.com/path
# HTTP/1.1 401 Unauthorized
403 Forbidden #

De server begreep het verzoek, maar weigert het te autoriseren. RFC 9110 §15.5.4.

Veelvoorkomende oorzaak

De gebruiker is geauthenticeerd maar mist toestemming, of de bron is geblokkeerd vanaf het IP / de regio van de gebruiker.

Wanneer gebruiken

Autorisatiefouten, IP-allowlists, op rollen gebaseerde toegangscontrole.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 403 Forbidden
404 Not Found #

De server kan geen actuele representatie van de doelbron vinden. Kan ook gebruikt worden om een 403 te verbergen. RFC 9110 §15.5.5.

Veelvoorkomende oorzaak

Typefout in de URL, verwijderde bron of bron die nooit heeft bestaan.

Wanneer gebruiken

Standaardresponse voor ontbrekende routes en bronnen. Wordt minder agressief gecached dan 410.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 404 Not Found
405 Method Not Allowed #

De methode wordt op de bron niet ondersteund. De response MOET een Allow-header bevatten met de ondersteunde methodes. RFC 9110 §15.5.6.

Veelvoorkomende oorzaak

DELETE aanroepen op een alleen-lezen-collectie, POST op een singleton-bron, etc.

Wanneer gebruiken

REST-API's die expliciet willen zijn over toegestane werkwoorden.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 405 Method Not Allowed
406 Not Acceptable #

De server kan geen representatie produceren die past bij de Accept-*-headers. RFC 9110 §15.5.7.

Veelvoorkomende oorzaak

De client vroeg om application/xml, maar alleen application/json is beschikbaar.

Wanneer gebruiken

Strikte content-onderhandeling. Veel API's vallen standaard terug op JSON in plaats van 406 te geven.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 406 Not Acceptable
408 Request Timeout #

De server gaf het op te wachten tot de client het verzoek afmaakte. RFC 9110 §15.5.9.

Veelvoorkomende oorzaak

Trage clientverbinding, half voltooide upload, idle keep-alive die de server-timeout overschreed.

Wanneer gebruiken

Reverse proxies en load balancers vóór trage clients.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 408 Request Timeout
409 Conflict #

Het verzoek conflicteert met de huidige staat van de bron. RFC 9110 §15.5.10.

Veelvoorkomende oorzaak

Twee clients die hetzelfde record gelijktijdig bewerken; schending van een unique constraint; PUT met een verouderde ETag.

Wanneer gebruiken

Optimistic concurrency control, idempotente create-eindpunten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 409 Conflict
410 Gone #

De bron is bewust verwijderd en zal niet terugkeren. RFC 9110 §15.5.11.

Veelvoorkomende oorzaak

Permanent verwijderde content; uitgefaseerd API-eindpunt dat is gepensioneerd.

Wanneer gebruiken

Verwijderde pagina's waar je crawlers de URL sneller wilt laten droppen dan met 404.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 410 Gone
411 Length Required #

Het verzoek mist een Content-Length-header die de server vereist. RFC 9110 §15.5.12.

Veelvoorkomende oorzaak

Een streamende client die de body niet bufferde of geen chunked transfer encoding gebruikte.

Wanneer gebruiken

Servers die op bepaalde eindpunten geen chunked uploads toestaan.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 411 Length Required
413 Content Too Large #

De body van het verzoek is groter dan de server wil accepteren. RFC 9110 §15.5.14. Hernoemd van "Payload Too Large" in RFC 9110.

Veelvoorkomende oorzaak

Upload boven de geconfigureerde maximumgrootte, bestand boven de maximale formuliergrootte.

Wanneer gebruiken

File-upload-eindpunten, JSON-API's met body-grootte-limieten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 413 Content Too Large
414 URI Too Long #

De verzoek-URI is langer dan de server bereid is te interpreteren. RFC 9110 §15.5.15.

Veelvoorkomende oorzaak

Enorme querystrings (vaak van formulieren met method=GET) of in de URL ingebedde tokens.

Wanneer gebruiken

Wanneer gebruikers je eindpunt aanroepen met abnormaal lange URL's — schakel het formulier over op POST.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 414 URI Too Long
415 Unsupported Media Type #

De server weigert de body in het formaat dat de Content-Type-header beschrijft te accepteren. RFC 9110 §15.5.16.

Veelvoorkomende oorzaak

application/xml sturen naar een JSON-only-eindpunt, ontbrekend of verkeerd Content-Type.

Wanneer gebruiken

REST-API's die strikt slechts één of twee mediatypes accepteren.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 415 Unsupported Media Type
418 I'm a teapot #

Een 1-aprilgrap uit RFC 2324 (HTCPCP). Sommige servers geven hem terug als generieke "weiger te zetten"-fout. Geen echte productiestatus.

Veelvoorkomende oorzaak

Software die 418 bewust teruggeeft, vaak om misbruikvallen of grappen aan te duiden.

Wanneer gebruiken

Alleen als easter egg. Niet gebruiken in echte API's — veel proxies en clients herkennen het niet.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 418 I'm a teapot
422 Unprocessable Content #

De syntax is goed, maar de server kan de semantische inhoud niet verwerken. RFC 9110 §15.5.21. Oorspronkelijk geïntroduceerd door WebDAV (RFC 4918).

Veelvoorkomende oorzaak

Validatiefouten op een structureel geldige JSON-payload — verplicht veld leeg, waarde buiten bereik.

Wanneer gebruiken

Formuliervalidatie in moderne API's. Schoner dan 400 omdat het verzoek syntactisch geldig is.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 422 Unprocessable Content
423 Locked #

De bron is vergrendeld. RFC 4918 (WebDAV).

Veelvoorkomende oorzaak

WebDAV-bron waarop een andere gebruiker een exclusieve vergrendeling heeft.

Wanneer gebruiken

Documentcollaboratie-servers, version-control-frontends.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 423 Locked
425 Too Early #

De server wil geen verzoek verwerken dat herhaald zou kunnen worden, meestal omdat het is verzonden in TLS 1.3 0-RTT (early data). RFC 8470.

Veelvoorkomende oorzaak

TLS 1.3 0-RTT-verzoek dat de server als onveilig voor replay beschouwt.

Wanneer gebruiken

Bescherm niet-idempotente eindpunten tegen replay tijdens 0-RTT-handshakes.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 425 Too Early
428 Precondition Required #

De origin-server vereist dat het verzoek conditioneel is. RFC 6585.

Veelvoorkomende oorzaak

De server wil dat clients If-Match / If-Unmodified-Since gebruiken om lost-update-conflicten te voorkomen.

Wanneer gebruiken

API's met optimistic locking die onvoorwaardelijke writes weigeren.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 428 Precondition Required
429 Too Many Requests #

De gebruiker heeft te veel verzoeken gedaan in een gegeven tijd. RFC 6585.

Veelvoorkomende oorzaak

Rate limit bereikt; de response bevat meestal een Retry-After-header.

Wanneer gebruiken

API's met rate limiting, login-throttling, misbruikbestrijding.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 429 Too Many Requests
431 Request Header Fields Too Large #

De server weigert het verzoek te verwerken omdat de header-velden te groot zijn. RFC 6585.

Veelvoorkomende oorzaak

Een te grote cookie, een extreem lange Referer- of Authorization-header.

Wanneer gebruiken

Wanneer sessiecookies boven je reverse-proxy-buffer uitkomen; overweeg trimmen of state in de body te zetten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 431 Request Header Fields Too Large
451 Unavailable For Legal Reasons #

De bron is niet beschikbaar door juridische eisen — een verwijderingsbevel, geo-block of DMCA. RFC 7725.

Veelvoorkomende oorzaak

Gerechtelijk bevel, takedown door een toezichthouder, AVG-recht-op-vergetelheid-response.

Wanneer gebruiken

Compliance-teams die transparant willen zijn over waarom een pagina is geblokkeerd.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 451 Unavailable For Legal Reasons
500 Internal Server Error #

De server is een onverwachte conditie tegengekomen die voorkwam dat hij het verzoek kon afhandelen. RFC 9110 §15.6.1.

Veelvoorkomende oorzaak

Onafgevangen exception, applicatiebug, kapotte dependency, hollende query.

Wanneer gebruiken

Catch-all-serverfout. Log altijd een stack trace en een request ID, zodat gebruikers die kunnen citeren.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 500 Internal Server Error
501 Not Implemented #

De server ondersteunt de functionaliteit die nodig is om het verzoek af te handelen niet. RFC 9110 §15.6.2.

Veelvoorkomende oorzaak

Onbekende methode, feature flag uitgeschakeld, code-pad gestubbed.

Wanneer gebruiken

API-eindpunten die bestaan maar nog niet zijn gebouwd. Verkies 405 als de methode fout is maar andere wel werken.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 501 Not Implemented
502 Bad Gateway #

De gateway of proxy ontving een ongeldige response van de upstream-server. RFC 9110 §15.6.3.

Veelvoorkomende oorzaak

Upstream stuurde misvormde HTTP terug, de verbinding brak halverwege de response, of de applicatie crashte.

Wanneer gebruiken

Reverse proxies (Nginx, Cloudflare, ALB) wanneer de applicatie erachter faalt.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 502 Bad Gateway
503 Service Unavailable #

De server kan het verzoek momenteel niet afhandelen, meestal door onderhoud of overbelasting. RFC 9110 §15.6.4.

Veelvoorkomende oorzaak

Onderhoudsvenster, de wachtrij is vol, autoscaler is achterop, bewuste brown-out.

Wanneer gebruiken

Geplande downtime of beveiliging tegen overbelasting. Stel altijd Retry-After in, zodat clients kunnen terugschakelen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 503 Service Unavailable
504 Gateway Timeout #

De gateway of proxy kreeg geen tijdige response van de upstream-server. RFC 9110 §15.6.5.

Veelvoorkomende oorzaak

Upstream deed langer dan de geconfigureerde timeout van de proxy om te reageren.

Wanneer gebruiken

Trage applicatiecode, geblokkeerde databasequery's, third-party-API's die hangen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 504 Gateway Timeout
505 HTTP Version Not Supported #

De server ondersteunt de major HTTP-versie van het verzoek niet. RFC 9110 §15.6.6.

Veelvoorkomende oorzaak

Client spreekt HTTP/2 met een server die alleen HTTP/1.0 doet, of stuurt een onbekend versietoken.

Wanneer gebruiken

Zelden in de praktijk. Verkeerd geconfigureerde edges of zeer oude clients.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 505 HTTP Version Not Supported
511 Network Authentication Required #

De client moet authenticeren om het netwerk te gebruiken — meestal een captive portal. RFC 6585.

Veelvoorkomende oorzaak

Hotel- of luchthaven-Wi-Fi die verkeer onderschept tot inloggen.

Wanneer gebruiken

Captive portals op tijdelijke netwerken. Servers geven dit normaal niet zelf terug.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 511 Network Authentication Required

Wat zijn HTTP-statuscodes?

Een HTTP-statuscode is het driecijferige getal dat een server aan het begin van elke response teruggeeft. Ze zijn ingedeeld in vijf families: 1xx informatief, 2xx succes, 3xx redirectie, 4xx clientfout en 5xx serverfout. De codes zijn gedefinieerd in RFC 9110 (de geconsolideerde 2022-spec die de oudere serie 7230–7235 vervangt), met uitbreidingen in RFC 6585 (extra 4xx/5xx), RFC 7725 (451), RFC 4918 (WebDAV) en RFC 8470 (425). De status correct lezen maakt het verschil tussen een bug binnen vijf minuten oplossen en een middag lang een spook najagen: een 404 van je CDN betekent dat het pad fout is, een 502 van je proxy betekent dat de applicatie is gecrasht, en een 401 zonder WWW-Authenticate-header is een verkeerd geconfigureerde backend. Deze pagina is een doorzoekbare cheat sheet — elke kaart bevat de officiële naam, een beschrijving op basis van de RFC, de typische oorzaak en concrete codefragmenten die je kunt plakken in curl, Python, JavaScript of PHP.

Hoe gebruik je de referentie

Typ een code of deel van een naam in het zoekvak, of filter op familie via de chips. Elke kaart klapt open en toont de technische beschrijving, veelvoorkomende oorzaken en een fragment in tabbladen dat je kunt aanpassen. Elke code heeft een eigen anker (bv. #404), zodat je teamdocumenten direct naar een specifieke status kunt linken.

Statuscode-families in één oogopslag

Bereik Familie Betekenis
1xxInformatiefVoorlopige responses; zelden zichtbaar op applicatieniveau.
2xxSuccesVerzoek is ontvangen, begrepen en geaccepteerd.
3xxRedirectieVerdere actie nodig (een andere URL, cachevalidatie, etc.).
4xxClientfoutHet verzoek had een probleem (foute invoer, ontbrekende auth, verkeerde methode).
5xxServerfoutDe server slaagde er niet in een ogenschijnlijk geldig verzoek uit te voeren.

Veelgestelde vragen

Waar komen deze codes vandaan?
RFC 9110 is de canonieke specificatie uit 2022 die de oudere reeks RFC 7231 consolideert. Aanvullende codes leven in RFC 6585 (428, 429, 431, 511), RFC 7725 (451), RFC 4918 (WebDAV) en RFC 8470 (425).
Moet ik 401 of 403 gebruiken?
401 betekent "je bent niet geauthenticeerd". 403 betekent "je bent geauthenticeerd maar mag het niet". Een 401 moet een WWW-Authenticate-header bevatten met de geaccepteerde schema's; een 403 moet die juist niet bevatten, omdat de credentials niet het probleem zijn.
Wat is het verschil tussen 301 en 308?
Beide signaleren een permanente redirect. 301 herschrijft historisch in veel clients POST naar GET, 308 behoudt de methode en body expliciet. Gebruik 308 in nieuwe API's.
Wanneer geeft mijn CDN 502 vs. 504 terug?
502 (Bad Gateway) betekent dat de upstream misvormde data terugstuurde of de verbinding sloot. 504 (Gateway Timeout) betekent dat de upstream te lang deed. CloudFront, Cloudflare en Nginx labelen ze in logs verschillend — beide duiden op een applicatieprobleem.
Moet ik 404 of 410 teruggeven voor verwijderde content?
Gebruik 410 wanneer de bron opzettelijk en permanent is verwijderd en je crawlers hem snel wilt laten droppen. 404 is prima voor typefouten en content die nog kan terugkomen; het is ook een verdedigbare response voor bronnen waarvan je niet wilt bevestigen dat ze bestaan.
Zijn de fragmenten veilig om te kopiëren?
Het zijn minimale templates bedoeld om te lezen en aan te passen. Valideer altijd je invoer, behandel fouten en respecteer de HTTP-semantiek in je eigen code — de voorbeelden slaan dat ter wille van de beknoptheid over.