HTTP-headers opzoeken

HTTP-headers opzoeken is een gratis tool die alle HTTP-responseheaders ophaalt die een URL bij een standaard GET-verzoek retourneert.

Wat zijn HTTP-responseheaders?

HTTP-responseheaders zijn metagegevens die een webserver vóór de responsebody verstuurt, zoals een HTML-pagina, afbeelding of JSON-document. Ze vertellen de client hoe die de response moet interpreteren, cachen, omleiden of beveiligen.

Een HTTP/1.x-response begint normaal gesproken met een HTTP-statusregel, gevolgd door de headers. Bij HTTP/2 en HTTP/3 staat de equivalente status in de pseudoheader :status. Technisch gezien staat de HTTP/1.x-statusregel los van de headers, maar meestal wordt deze erbij getoond omdat hij aangeeft of het verzoek is geslaagd. Status 200 betekent bijvoorbeeld dat de resource is geretourneerd, 301 of 302 duidt op een omleiding, 404 betekent dat de resource niet is gevonden en 500 wijst op een fout aan de serverzijde.

Headers kunnen afkomstig zijn van de oorspronkelijke server, een reverse proxy of een content delivery network zoals Cloudflare. Terwijl de response door deze systemen loopt, kunnen headers worden toegevoegd of verwijderd. Het resultaat kan dus meer beschrijven dan alleen de applicatie die de pagina heeft gegenereerd.

Hoe zoek ik HTTP-headers op?

Voer de volledige URL in die je wilt controleren, inclusief het schema, bijvoorbeeld https://www.example.com/account. De tool verstuurt vanaf zijn server een standaard GET-verzoek en toont de HTTP-headers die van die URL worden ontvangen.

Wil je responseheaders nauwkeurig vergelijken, gebruik dan precies de URL-varianten die je wilt onderzoeken. De headers voor http://example.com, https://example.com en https://www.example.com kunnen verschillen, omdat elk adres eigen omleidingen, cacheregels en serverinstellingen kan hebben.

Ook de opbouw van de URL beïnvloedt het verzoek:

• Spaties zijn niet geldig als onbewerkte URL-tekens en moeten normaal gesproken met procentcodering worden gecodeerd, in een pad meestal als %20.
• ? markeert het begin van de querycomponent. & en = worden vaak gebruikt bij querycodering in formulierstijl, maar hebben niet in elke querystring die functie.
• Domeinnamen met accenten of niet-Latijnse tekens worden verwerkt met IDNA en weergegeven als ASCII A-labels, die vaak beginnen met xn--. Tekens in een pad worden doorgaans eerst als UTF-8-bytes gecodeerd en daarna voorzien van procentcodering.
• Een fragment dat begint met # wordt door de browser verwerkt en niet meegestuurd in het HTTP-verzoek.
• Er bestaat geen universele maximale URL-lengte. Zeer lange URL's kunnen door een server, proxy of applicatie worden geweigerd.

Hoe lees ik het resultaat?

Bekijk de headers die verband houden met het probleem dat je onderzoekt. Bij headernamen maakt het gebruik van hoofdletters en kleine letters niet uit, maar de syntaxis van hun waarden kan daar wel gevoelig voor zijn.

Andere headers kunnen specifiek zijn voor een applicatie. Zo bepaalt Access-Control-Allow-Origin welke origins een response mogen lezen via cross-originverzoeken van een browser. Een Server-header kan software of een proxy vermelden, maar vormt geen betrouwbaar bewijs voor het onderliggende platform. Beheerders kunnen deze header namelijk aanpassen of verwijderen.

Praktische scenario's voor probleemoplossing

Problemen met omleidingen zijn een veelvoorkomende reden om headers te bekijken. Stel dat https://example.com/old-page status 301 retourneert met Location: https://example.com/new-page. De server geeft de client dan opdracht om het nieuwe adres op te vragen. Door elke bestemming afzonderlijk te controleren, kun je een omleidingslus of een onverwachte wisseling tussen HTTP en HTTPS ontdekken.

Zie je een verouderde pagina achter Cloudflare of een ander CDN, controleer dan Cache-Control, Age, ETag en eventuele providerspecifieke cacheheaders. Een hoge waarde voor Age geeft de berekende leeftijd van de gecachte response aan, mogelijk inclusief tijd in bovenliggende caches. De waarde zegt dus niet hoe lang één specifieke tussenliggende server de response heeft bewaard. Ook bewijst deze niet dat elke regionale cache dezelfde versie bevat.

Werkt een API wel in een serverscript maar niet in een browser, bekijk dan Content-Type en de CORS-responseheaders, waaronder Access-Control-Allow-Origin. Als een JSON-endpoint text/html retourneert, kan het in werkelijkheid een foutpagina of inlogscherm leveren. Door ontbrekende toestemming voor cross-originverzoeken kan een browser de toegang blokkeren, zelfs als de server status 200 retourneert.

Headers kunnen ook helpen als een website niet bereikbaar lijkt. Een 503-response wijst op een tijdelijke storing van de server of een bovenliggende dienst, terwijl 404 betekent dat het opgevraagde pad niet is gevonden. Headers kunnen niet elke storing verklaren. Als de DNS-resolutie, TCP-verbinding of TLS-onderhandeling mislukt voordat er een HTTP-response is, zijn er mogelijk geen responseheaders om te bekijken. Ping biedt een afzonderlijke controle van de verbinding, terwijl de HTTP/2-controleur de protocolondersteuning kan controleren.

Waarom kan een correct resultaat toch verkeerd lijken?

Een correct resultaat kan afwijken van wat je browser toont, omdat caches, DNS-records en de context van het verzoek de twee verzoeken naar verschillende responses kunnen leiden. Deze zoekopdracht wordt op de server uitgevoerd. Daardoor kan de tool een ander CDN-knooppunt bereiken of een onlangs gewijzigd DNS-record eerder of later verwerken dan je lokale netwerk.

Browsers sturen bovendien hun eigen cookies, geaccepteerde inhoudstypen, talen en cachevalidators mee. Een WordPress-pagina waarop je bent ingelogd, kan daarom andere cacheregels retourneren dan een anoniem verzoek vanaf een server. Geografische routering en systemen voor botbeheer kunnen een response eveneens aanpassen op basis van het bronnetwerk of de requestheaders.

Na een DNS-wijziging kunnen caching resolvers het vorige record blijven gebruiken totdat de geldigheidsduur ervan verloopt. Zodra het verkeer de nieuwe server bereikt, kan een oud CDN-object of de browsercache nog steeds eerdere inhoud terugsturen. Controleer de omgezette host afzonderlijk, wis caches waar dat passend is en vergelijk exact dezelfde URL. Ga er niet van uit dat elke hostnaam dezelfde configuratie gebruikt.

Veelgestelde vragen

Laat deze tool ook de requestheaders zien?

Nee. De tool haalt de responseheaders op die de URL bij een standaard GET-verzoek retourneert. Requestheaders zijn de metagegevens die naar de server worden gestuurd. Om deze volledig te bekijken, heb je aparte ontwikkelaarstools in de browser, serverlogboeken of een opdrachtregelclient nodig.

Blijven ingevoerde URL's privé?

De zoekopdracht wordt op de server uitgevoerd. Je invoer wordt via HTTPS naar die server verstuurd en niet opgeslagen. Voer geen URL's in die wachtwoorden, toegangstokens of gevoelige queryparameters bevatten. De doelserver ontvangt deze waarden namelijk ook wanneer de URL wordt opgevraagd.

Kunnen HTTP-headers een certificaatwaarschuwing verklaren?

Meestal niet zonder aanvullende informatie. De TLS-verbinding wordt tot stand gebracht voordat de HTTP-response wordt verstuurd. Een verlopen certificaat, niet-overeenkomende hostnaam of niet-vertrouwde uitgever kan er daarom voor zorgen dat er helemaal geen headers worden geretourneerd. Verschijnt de browserwaarschuwing voordat de pagina wordt geladen, controleer dan het certificaat en de certificaatketen afzonderlijk.

Waarom krijg ik meerdere Set-Cookie-headers terug?

Een response kan meerdere cookies instellen en elke cookie gebruikt een eigen Set-Cookie-veld. Voeg deze velden niet samen alsof ze een door komma's gescheiden lijst vormen, want de vervaldatums van cookies kunnen zelf komma's bevatten. Controleer voor elke cookie afzonderlijk het domein, het pad en de beveiligingskenmerken.

Kan ik het resultaat vergelijken met curl?

Ja. Een opdracht zoals curl -D - https://example.com/ -o /dev/null toont de responseheaders en negeert de body. Verschillende curl-versies, requestheaders, instellingen voor omleidingen en netwerklocaties kunnen andere resultaten opleveren. Zorg daarom dat die omstandigheden overeenkomen voordat je een verschil als serverfout beschouwt.