HTTP-headers

De startlijn zegt wat je wil, de body bevat de gegevens. Alles daartussen zijn headers: sleutel-waardeparen met metadata over het bericht.

GET /posts/1 HTTP/1.1          ← startlijn
Host: jsonplaceholder.typicode.com    ┐
Accept: application/json              ├ headers
Authorization: Bearer eyJhbGci...     ┘
                               ← lege regel
(body, indien aanwezig)

Die lege regel is niet decoratief: ze markeert het einde van de headers. Alles erna is body.

Headers lijken bijzaak tot je iets debugt. Dan blijkt dat de helft van je problemen erin staat: een ontbrekende Content-Type, een token dat niet meegestuurd wordt, een cache die te lang blijft plakken, of een Access-Control-Allow-Origin die er niet is.

Request-headers: wat de client meestuurt

Header	Voorbeeld	Waarvoor
Host	Host: www.ap.be	Voor welk domein het verzoek bedoeld is. Verplicht in HTTP/1.1
User-Agent	User-Agent: Mozilla/5.0 ...	Welke client het verzoek stuurt
Accept	Accept: application/json	Welke formaten de client aankan
Accept-Language	Accept-Language: nl-BE, nl;q=0.9	In welke taal het antwoord het liefst is
Authorization	Authorization: Bearer eyJhbGci...	Wie je bent. Nodig bij elk request, want HTTP is stateless
Content-Type	Content-Type: application/json	Het formaat van de body die je meestuurt
Content-Length	Content-Length: 47	Hoe groot die body is
Cookie	Cookie: session=abc123	Cookies die je eerder van deze server kreeg
Origin	Origin: http://localhost:5173	Vanaf welke site het verzoek vertrekt. Zie CORS

Waarom Host verplicht is

Eén server met één IP-adres bedient vaak honderden domeinen. Het pad /index.html is dan niet genoeg: pas met Host: www.ap.be weet nginx welke site je bedoelt. Dat is ook waarom de host in de TLS-handdruk apart meegestuurd wordt: het certificaat moet gekozen worden vóór het request leesbaar is.

Response-headers: wat de server meegeeft

Header	Voorbeeld	Waarvoor
Content-Type	Content-Type: text/html; charset=UTF-8	Hoe de body geïnterpreteerd moet worden
Content-Length	Content-Length: 4823	Grootte van de body in bytes
Cache-Control	Cache-Control: max-age=3600	Hoelang de client dit mag bewaren
Location	Location: https://ap.be/nieuw	Waar de client naartoe moet bij een 3xx
Set-Cookie	Set-Cookie: session=abc123; HttpOnly	Een cookie dat de client moet bewaren
Access-Control-Allow-Origin	Access-Control-Allow-Origin: *	Welke andere origins de response mogen lezen
Server	Server: nginx/1.24.0	Welke serversoftware antwoordde
Retry-After	Retry-After: 120	Wanneer je het opnieuw mag proberen na 429 of 503

Content-Type: de header die het vaakst fout zit

Content-Type zegt hoe de bytes gelezen moeten worden. Klopt hij niet, dan gaat het mis, ook al is de inhoud perfect.

Waarde	Waarvoor
text/html	Een webpagina
application/json	API-data
application/x-www-form-urlencoded	Een gewoon HTML-formulier
multipart/form-data	Een formulier met bestandsupload
image/png, image/jpeg	Afbeeldingen
text/plain	Platte tekst

De fout die iedereen één keer maakt

curl -X POST https://voorbeeld.be/api/gebruikers -d '{"naam": "Robin"}'

Dit stuurt je JSON, maar curl zet er zelf Content-Type: application/x-www-form-urlencoded bij. De server probeert je JSON dan als formulierdata te lezen en antwoordt met 400 Bad Request. Voeg de juiste header toe:

curl -X POST https://voorbeeld.be/api/gebruikers \
  -H "Content-Type: application/json" \
  -d '{"naam": "Robin"}'

Headers bekijken

In DevTools

Klik een request aan in de Network tab en ga naar Headers. Je krijgt drie blokken:

Blok	Wat er staat
General	URL, methode, statuscode, het adres van de server
Response Headers	Wat de server meegaf
Request Headers	Wat je browser verstuurde

Dat onderscheid is belangrijk bij het debuggen: zoek je een token, dan kijk je bij Request Headers; zoek je waarom iets geblokkeerd wordt, dan bij Response Headers.

Met curl

curl -I https://ap.be                      # Enkel de response headers (stuurt een HEAD)
curl -v https://ap.be                      # Request én response, met headers
curl -H "Accept: application/json" https://api.voorbeeld.be/producten
curl -H "Authorization: Bearer mijntoken" https://api.voorbeeld.be/profiel

In de uitvoer van -v beginnen jouw headers met > en die van de server met <:

> GET / HTTP/1.1
> Host: ap.be
> User-Agent: curl/8.1.2
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Cache-Control: max-age=600
<

Test jezelf

1. Je stuurt een JSON-body maar krijgt `400 Bad Request`. Welke header controleer je eerst?

2. In welk blok van DevTools zoek je of je token wel degelijk meeging?

3. Waarom is de `Host`-header verplicht in HTTP/1.1?

Onthoud

• Headers zijn sleutel-waardeparen tussen de startlijn en de body, afgesloten door een lege regel.
• Belangrijke request-headers: Host (verplicht), Accept, Content-Type, Authorization, Cookie, Origin.
• Belangrijke response-headers: Content-Type, Cache-Control, Location, Set-Cookie, Access-Control-Allow-Origin.
• Content-Type beschrijft de body van het bericht waarin hij staat: in een request die van jou, in een response die van de server.
• In DevTools staan Request Headers en Response Headers in aparte blokken; curl -v toont ze met > en <.