Een kleine toolkit voor het debuggen van redirects en HTTP-headers in productie

Het probleem met HTTP debuggen in productie

De meeste HTTP-problemen zijn onzichtbaar in de browser. Een redirectketen faalt stilletjes, een cacheheader wijkt één teken af, een CORS-beleid blokkeert een request zonder uitleg. De developer tools van de browser laten je het resultaat van het gesprek zien, maar verbergen vaak de ruwe uitwisseling die het probleem veroorzaakte.

Dat is vooral belangrijk in productie, waar je niet zomaar logging kunt toevoegen of services opnieuw kunt starten om te zien wat er is veranderd. Je hebt tools nodig die het daadwerkelijke HTTP-gesprek tonen: requestheaders, responseheaders, statuscodes, redirectdoelen, timing. Hier zijn de vijf tools die dat betrouwbaar doen, plus de browsertechnieken die ze aanvullen.

curl: de basis

curl is de eerste tool om naar te grijpen, omdat die precies laat zien wat de server heeft verzonden, zonder browserinterpretatie ertussen.

Om responseheaders zonder body te zien:

curl -I https://example.com

Om redirects te volgen en elke stap te zien:

curl -L -v https://example.com

De -v-flag (verbose) toont het volledige request en de volledige response, inclusief alle headers. De -L-flag volgt redirects automatisch. Samen laten ze de volledige redirectketen zien, en daar zitten de meeste productieproblemen.

Om alleen de redirectlocaties te zien:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Dit is nuttig wanneer je een redirectketen wilt controleren zonder de ruis van volledige headers. De -w-flag formatteert de output zodat alleen de statuscode en de volgende URL in de keten worden getoond.

Met curl kun je ook aangepaste headers sturen, wat essentieel is voor het testen van CDN-gedrag, authenticatie of API-endpoints:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl met betere defaults

httpie is een Python-tool die doet wat curl doet, maar met syntaxis die makkelijker te onthouden is en output die makkelijker te lezen is. Het is geen vervanging—curl is krachtiger en breder geïnstalleerd—maar voor snelle controles is httpie sneller.

Om headers te zien:

http HEAD https://example.com

Om redirects te volgen:

http --follow --all https://example.com

De --all-flag toont elke response in de redirectketen, niet alleen de laatste. Dit is het equivalent van curl -L -v, maar de output is kleurgecodeerd en makkelijker te scannen.

Om JSON te verzenden:

http POST https://api.example.com name=value

httpie gaat standaard uit van JSON, wat typwerk bespaart wanneer je API's test. Het geeft de response ook netjes geformatteerd weer, waardoor verkeerd gevormde headers of onverwachte waarden makkelijker opvallen.

Browser DevTools: Network-tab

De Network-tab van de browser is waar je moet beginnen als het probleem alleen in de browser optreedt. Die toont dezelfde informatie als curl, maar laat ook de interpretatie van de browser zien: of een request is geblokkeerd, hoe caching is afgehandeld, of cookies zijn meegestuurd.

Om de volledige request- en responseheaders te zien, klik je op een request in de Network-tab en kijk je vervolgens in de sectie Headers. De "Raw"-weergave toont de headers precies zoals ze zijn verzonden, zonder opmaak.

Om redirectketens te zien, zoek je naar requests met 3xx-statuscodes. De browser groepeert ze onder het uiteindelijke request, maar je kunt ze uitklappen om elke stap te zien. Daar vind je redirectloops, ontbrekende Location-headers of redirects die naar het verkeerde domein wijzen.

Om timing te zien, kijk je naar de Timing-tab van een request. Die laat zien hoeveel tijd de browser besteedde aan DNS-lookup, TCP-verbinding, TLS-handshake en wachten op de server. Als een redirect traag is, vertelt de timing-tab je of het probleem netwerklatentie of serververwerking is.

Eén beperking: de browser verbergt sommige headers om veiligheidsredenen. Set-Cookie-headers zijn zichtbaar, maar de daadwerkelijke cookiewaarden worden gemaskeerd. Authorization-headers zijn soms helemaal verborgen. Als je die moet zien, gebruik dan curl.

mitmproxy: de onderscheppende proxy

mitmproxy is een Python-tool die tussen je browser en de server zit en elk request en elke response in realtime toont. Het is complexer dan curl, maar het is de enige tool die laat zien wat de browser daadwerkelijk verzendt, inclusief headers die de browser automatisch toevoegt.

Om te starten:

mitmproxy

Configureer daarna je browser om localhost:8080 als HTTP-proxy te gebruiken. mitmproxy toont elk request in een terminalinterface. Je kunt headers inspecteren, requests bewerken voordat ze worden verzonden, of requests opnieuw afspelen met andere parameters.

Dit is nuttig voor het debuggen van problemen die alleen in de browser optreden: CORS-preflightrequests, cookieafhandeling of requests die falen wanneer bepaalde headers aanwezig zijn. Het is ook nuttig om te testen hoe je site zich gedraagt achter een bedrijfsproxy of VPN, omdat mitmproxy zulke omgevingen kan simuleren.

Het nadeel is de complexiteit van de setup. Je moet een rootcertificaat installeren zodat mitmproxy HTTPS-verkeer kan onderscheppen, en je moet je browser configureren om de proxy te gebruiken. Voor snelle controles is curl sneller. Voor diepgaand debuggen is mitmproxy de setuptijd waard.

WebPageTest: perspectief vanuit productie

WebPageTest is een gratis service die je pagina laadt vanuit echte browsers op verschillende locaties en je het volledige HTTP-gesprek laat zien. Het is langzamer dan curl, maar het toont wat echte gebruikers ervaren, inclusief CDN-gedrag, DNS-resolutie en TLS-onderhandeling.

De "Request Headers"- en "Response Headers"-weergaven laten precies zien wat de browser heeft verzonden en ontvangen. De "Waterfall"-weergave toont de timing van elk request, inclusief redirects. Daar vind je problemen die alleen in bepaalde regio's of op bepaalde netwerken optreden.

WebPageTest toont ook de redirectketen voor het hoofddocument, en daar zitten de meeste redirectproblemen. Als je site redirect van http:// naar https://, daarna van www. naar non-www., en vervolgens van / naar /en/, dan toont WebPageTest alle drie de stappen en hoelang elke stap duurde.

Voor tools die je helpen deze HTTP-basisprincipes te valideren en te optimaliseren, biedt Wux Webtools verschillende utilities die volledig in je browser draaien, waaronder headeranalysers en redirectcheckers die je privacy respecteren door alles client-side te verwerken.

Wanneer headers liegen

De lastigste HTTP-problemen zijn die waarbij de server tegenstrijdige headers verzendt. Een Cache-Control-header zegt no-cache, maar een Expires-header zegt dat de resource een jaar geldig is. Een Location-header wijst naar een relatieve URL, maar de Content-Location-header wijst ergens anders heen. De browser moet raden welke header hij moet vertrouwen, en verschillende browsers raden verschillend.

Wanneer dit gebeurt, moet je de ruwe headers zien in de volgorde waarin de server ze heeft verzonden. curl -v doet dit. mitmproxy ook. De DevTools van de browser herschikken headers soms voor de leesbaarheid, waardoor het probleem verborgen blijft.

Een ander veelvoorkomend probleem: headers die worden toegevoegd door een CDN of loadbalancer, niet door je applicatie. Als je een cachingprobleem debugt, moet je weten of de Cache-Control-header afkomstig is van je app of van de CDN. curl toont het eindresultaat, maar vertelt niet waar elke header vandaan komt. Daarvoor moet je de CDN omzeilen (door de originserver rechtstreeks te benaderen) en de headers vergelijken.

Het probleem met redirectloops

Redirectloops zijn het meest voorkomende HTTP-probleem in productie. Ze ontstaan wanneer twee servers het niet eens zijn over waar een URL naartoe moet wijzen: de CDN redirect naar de origin, de origin redirect terug naar de CDN. Of de loadbalancer redirect HTTP naar HTTPS, maar de app redirect HTTPS terug naar HTTP omdat die de X-Forwarded-Proto-header niet ziet.

Om dit te debuggen, moet je de volledige redirectketen zien, inclusief de Location-header bij elke stap. curl -L -v doet dit, maar stopt na 50 redirects om oneindige loops te voorkomen. Als je die limiet raakt, heb je een redirectloop.

De oplossing is meestal een configuratiewijziging: vertel de app dat die de X-Forwarded-Proto-header moet vertrouwen, of vertel de CDN dat requests die al HTTPS zijn niet opnieuw moeten worden geredirect. Maar je kunt het niet oplossen totdat je de loop ziet, en de browser toont niet meer dan een paar redirects voordat hij opgeeft.

Wat je eerst moet controleren

Wanneer er iets stukgaat in productie, controleer dan deze punten in volgorde:

1. Statuscode: Is die wat je verwachtte? Een 301 is permanent, een 302 is tijdelijk, een 307 behoudt de HTTP-methode. Als je de verkeerde code ziet, zit het probleem in je redirectconfiguratie.

1. Location-header: Wijst die naar de juiste plek? Is het een absolute URL of een relatieve? Relatieve URL's worden opgelost ten opzichte van de huidige URL, wat onverwachte resultaten kan opleveren als de basis-URL niet is wat je denkt.

1. Cacheheaders: Cachet de browser de redirect? Een 301-redirect wordt standaard gecachet, wat betekent dat een verkeerd geconfigureerde redirect je site urenlang kan breken, zelfs nadat je hem hebt opgelost. Controleer de Cache-Control- en Expires-headers om te zien hoelang de browser de redirect zal onthouden.

1. CORS-headers: Als het request cross-origin is, verzendt de server dan de juiste Access-Control-Allow-Origin-header? Zo niet, dan blokkeert de browser het request en zie je een CORS-fout in de console. De responseheaders van de server zijn de enige plek om dit op te lossen—je kunt er in de browser niet omheen werken.

1. Timing: Hoelang duurde het request? Als het traag is, gaat het dan om netwerklatentie of serververwerking? Zowel de DevTools van de browser als WebPageTest tonen timingoverzichten die laten zien waar de tijd naartoe ging.

Voor een diepere blik op hoe browsergedrag rond privacy en headers is verschoven, zie wat er in 2026 is veranderd voor cookies en wat je eraan kunt doen, waarin de header- en consentimplicaties van recente browserupdates worden behandeld.

Belangrijkste punten

• curl -L -v toont de volledige redirectketen en alle headers, zonder browserinterpretatie
• De Network-tab van de browser laat zien wat de browser met de response deed, inclusief caching- en CORS-beslissingen
• mitmproxy laat zien wat de browser verzond, inclusief headers die de browser automatisch toevoegt
• WebPageTest laat zien wat echte gebruikers ervaren, inclusief CDN-gedrag en regionale verschillen
• Redirectloops en tegenstrijdige headers zijn de meest voorkomende productieproblemen, en ze zijn onzichtbaar zonder ruwe HTTP-inspectie

FAQ

Q: Waarom toont curl andere headers dan de browser?

A: Omdat de browser automatisch headers toevoegt (User-Agent, Accept, Cookie) en zijn eigen regels volgt voor caching en CORS. curl verzendt alleen wat jij aangeeft. Gebruik mitmproxy of de DevTools van de browser om te zien wat de browser daadwerkelijk verzendt.

Q: Hoe debug ik een redirect die alleen voor sommige gebruikers optreedt?

A: Controleer of de redirect afhangt van headers die de gebruiker verzendt: User-Agent, Accept-Language, Cookie of IP-adres (via X-Forwarded-For). Gebruik curl om dezelfde headers te verzenden als de gebruiker, of gebruik WebPageTest om de pagina te laden vanaf de locatie van de gebruiker.

Q: Wat is het verschil tussen 301- en 302-redirects?

A: Een 301 is permanent en vertelt de browser dat hij de redirect moet cachen (soms voor altijd). Een 302 is tijdelijk en vertelt de browser dat hij die niet moet cachen. Als je niet zeker weet welke je moet gebruiken, gebruik dan 302—je kunt die later altijd wijzigen naar 301.

Q: Waarom werkt mijn redirect in curl maar niet in de browser?

A: Waarschijnlijk omdat de browser een oude redirect cachet, of omdat de browser de redirect blokkeert vanwege CORS- of mixed-contentregels. Controleer de DevTools-console van de browser op fouten en controleer de Cache-Control-headers om te zien of de browser een gecachete response gebruikt.

Q: Hoe zie ik de headers die een CDN toevoegt?

A: Gebruik curl om de CDN-URL te benaderen en gebruik daarna opnieuw curl om de originserver rechtstreeks te benaderen (waarbij je de CDN omzeilt). Vergelijk de headers. De headers die alleen in de eerste response verschijnen, kwamen van de CDN.

<!-- tool-cta:start -->

💡 Probeer dit: Bij het opsporen van redirectproblemen traceert Redirect Checker de volledige keten en toont de statuscodes en headers bij elke hop.

<!-- tool-cta:end -->

Bronnen

• curl documentation — Officiële referentie voor commandlineopties en gedrag van curl
• HTTPie documentation — Gids voor httpie-syntaxis en functies
• MDN Web Docs: HTTP redirections — Uitgebreide uitleg van HTTP-redirectstatuscodes en gedrag
• WebPageTest documentation — Hoe je WebPageTest-resultaten en headers interpreteert