HTTP-headerparser

Plak een volledig HTTP-verzoek of -antwoord — het blok dat curl -v afdrukt, of wat het netwerkpaneel van de browser toont — en elke headerregel wordt ontleed: de naam, de waarde, een zin in gewoon Nederlands over wat hij doet, en het document dat hem definieert. Set-Cookie wordt attribuut voor attribuut uit elkaar gehaald (Secure, HttpOnly, SameSite, Max-Age, Expires…), parameters van Content-Type en Accept worden uitgewerkt, en het blok wordt gecontroleerd op de klassieke structurele problemen: verouderde gevouwen regels, illegale tekens, dubbele headers en headers die de verkeerde kant op worden gestuurd. Alles draait in uw browser en er wordt niets geüpload.
Automatisch kijkt naar de eerste regel: een verzoekregel (GET /pad HTTP/1.1) betekent verzoek, een statusregel (HTTP/1.1 200 OK) betekent antwoord, al het andere wordt gelezen als een kaal headerblok. De andere keuzes forceren de richting, wat bepaalt welke waarschuwingen gelden.
Nog niets ontleed. Plak hierboven een verzoek- of antwoordblok en druk op Headers ontleden, of druk op Voorbeeld voor een uitgewerkt voorbeeld.
Waar u een blok vandaan haalt dat het ontleden waard is. In een terminal drukt curl -v https://example.com/ 2>&1 het verzoek en het antwoord af met de voorvoegsels > en < — haal die weg en plak. curl -sI https://example.com/ geeft alleen het antwoordheaderblok. In de browser: open de ontwikkelaarstools, tabblad Netwerk, ververs, selecteer het documentverzoek en gebruik Kopiëren → Antwoordheaders kopiëren; voor de verzoekkant gebruikt u Kopiëren als cURL en leest u de vlaggen. Een kaal blok met Naam: waarde-regels zonder startregel wordt ook geparset — de richtingscontroles worden dan versoepeld.
Zelftest
Draait de parser opnieuw tegen vaste blokken: detectie van de richting, beide voorbeeldpools, elke regel voor Set-Cookie-attributen (SameSite=None zonder Secure, een niet-numerieke Max-Age, een kapotte Expires, een onbekend attribuut, een cookie zonder gelijkteken), samenvoegen van obs-fold, illegale veldnamen, dubbele headers, richtingsconflicten en de negatieve paden. Er wordt niets ergens naartoe gestuurd.
Wat is een HTTP-header?
In één zin: een HTTP-bericht is een startregel, een blok van Naam: waarde-regels die headers heten, een lege regel, en een optionele body — de headers dragen alles over het bericht behalve de body zelf: wie het heeft verstuurd, wat het kan accepteren, hoe het wordt gecachet, hoe het wordt geauthenticeerd en wat de afzender terug wil.
De vier families
FamilieReist mee opVoorbeeldenBeantwoordt de vraag
Verzoekheadersclient → serverHost, Accept, Cookie, Referer, Authorizationwat de client wil en wie hij zegt te zijn
Antwoordheadersserver → clientLocation, Server, Set-Cookie, Retry-Afterwat de server deed en wat hij als tegenprestatie vraagt
Representatieheadersbeide, over de bodyContent-Type, Content-Length, Content-Encoding, ETagin welk formaat de body is en welke kopie dit is
Besturingsheadersbeide, over de verbindingCache-Control, Connection, Via, Transfer-Encodinghoe het bericht en de verbinding onderweg worden behandeld

Sommige headers zijn stellig eenrichtingsverkeer: If-None-Match heeft alleen zin in een verzoek en Set-Cookie alleen in een antwoord. Parsen in de verkeerde richting is een van de klassieke kopieer-en-plak-debugfouten, daarom meldt deze pagina het.

De grammatica van een headerregel

RFC 9110 definieert een veldregel als field-name ":" OWS field-value OWS — een naam die alleen uit tokentekens bestaat (letters, cijfers en !#$%&'*+-.^_`|~), een dubbele punt met geen spatie ervoor, en een waarde van zichtbare tekens, spaties en tabs. Header namen zijn hoofdlettergevoelig (content-type is gelijk aan Content-Type); waarden zijn bijna altijd hoofdlettergevoelig. Een regel die begint met een spatie of tab zette vroeger de vorige header voort — obs-fold, sinds 2014 verouderd: een proxy die het ontvouwt kan veranderen wat de header betekent, dus de parser hier voegt het samen maar waarschuwt u dat het er is.

Veelgemaakte fouten
  • Vertrouwen op X-Forwarded-For. Het wordt door elke proxy op het pad toegevoegd, en een client kan de eerste hop vervalsen. Het vertelt u wat een keten van proxy's beweert, niet wie er verbonden is; behandel het als een hint, en geef de voorkeur aan een proxy die u beheert en die het overschrijft.
  • Alleen de antwoordheaders lezen. De helft van de interessante fouten (een dubbele Accept, een ontbrekende Host, een autorisatieheader die naar de verkeerde host wijst) zit in het verzoek, dat de browser standaard verbergt. Gebruik Kopiëren als cURL om uw eigen verzoek te zien.
  • Samenvoegen van Set-Cookie-regels. De meeste dubbele headers mogen met komma's worden gecombineerd — Set-Cookie mag dat niet, omdat de komma in de waarde zelf voorkomt. Browsers behandelen elke regel als een afzonderlijke cookie.
  • Verwachten dat Content-Length de bodygrootte is die u schreef. Het is de grootte na toepassing van Content-Encoding, en alleen wanneer het bericht niet gechunkt is; een antwoord met Transfer-Encoding: chunked heeft geen betekenisvolle enkele lengte.
  • Headers beoordelen op hun X--voorvoegsel. De conventie is gestorven in RFC 6648: X-Forwarded-For en X-Content-Type-Options zijn permanente de-facto-standaarden, terwijl veel niet-X-headers experimenteel zijn. Beoordeel op het definiërende document, niet op het voorvoegsel.
Veelgestelde vragen

Is het veilig om headers hier te plakken? Het parsen gebeurt volledig in uw browser en er wordt niets geüpload. Dat gezegd hebbende, is een gekopieerd headerblok een vingerafdruk: cookies, autorisatieheaders en de exacte User-Agent kunnen samen u identificeren, dus parse blokken die u een collega niet zou tonen.

Waarom toont mijn browser headers zoals :status die deze pagina fouten noemt? Dat zijn pseudo-headers van HTTP/2 en HTTP/3 — de binaire framinglagen vervangen de startregel en Host door pseudovelden. Deze pagina parseert de klassieke HTTP/1.1-draadtekst; pseudo-headers zijn dezelfde informatie nadat het protocol die heeft vertaald.

Wat is er met X-XSS-Protection gebeurd? Het is verouderd: de auditor die het aanstuurde veroorzaakte zelf beveiligingsfouten en browsers hebben het verwijderd. De taak ervan hoort bij een Content-Security-Policy — bouw er een op de CSP-generator en controleer de hele set op de controle op beveiligingsheaders.

Hoe wordt een Set-Cookie-attribuut gecontroleerd? Tegen RFC 6265: namen en waarden worden gesplitst bij het eerste gelijkteken, attributen na de eerste puntkomma, Expires moet een datum in het cookieformaat zijn, Max-Age cijfers, SameSite een van Strict/Lax/None — en None zonder Secure wordt door huidige browsers geweigerd, dus dat wordt aangestipt.

Kan ik alleen een lijst met headerregels parsen? Ja — kies Alleen headerblok en plak zonder startregel. De richtingscontroles worden versoepeld; al het andere (structuur, Set-Cookie, parameters) draait nog steeds.