Zum Inhalt springen
100% lokal

HTTP Header Parser

Analysiert eingefügte rohe HTTP-Anfrage- oder Antwortheader in lesbare Name-Wert-Paare.

Eingabe
Ausgabe

HTTP Header Parser

Kopieren Sie rohe HTTP-Header aus den Browser-Entwicklertools, curl -i, Proxy-Logs oder API-Dokumentation und dieses Tool zerlegt sie in die erste Zeile (Request-Methode und Ziel oder HTTP-Statuscode) sowie jeden Header als sauberes Name-Wert-Paar. Das spart die manuelle Arbeit, einen bestimmten Header in einer Wand von "Name: value"-Zeilen zu suchen.

Aktivieren Sie "Zusammengesetzte Header erweitern", um mehrteilige Headers wie Cache-Control und Content-Security-Policy in einzelne Direktiven zu zerlegen — damit wird "no-cache, no-store, must-revalidate" zu drei separaten, leicht zu scannenden Einträgen statt einer langen Zeichenkette, die Sie selbst aufschlüsseln müssen. "Großschreibung von Headernamen normalisieren" schreibt Namen in ihre konventionelle Form um (content-type wird zu Content-Type), unabhängig davon, wie sie in der Quelle vorkamen, da HTTP-Header-Namen im Netzwerk case-insensitiv sind, in der Praxis aber inkonsistent verwendet werden. Sortieren Sie die Liste alphabetisch, um einen bestimmten Header schnell in einer langen Response zu finden, und wechseln Sie die Ausgabe zwischen einer ausgerichteten Texttabelle und JSON, wenn Sie das Ergebnis in ein Skript einfügen möchten statt es mit den Augen zu lesen.

Aktivieren Sie "Vor fehlenden Sicherheits-Headern warnen", um die Ergebnisse gegen sechs häufig empfohlene Header zu prüfen — Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy und Permissions-Policy — und zeigen Sie an, welche fehlen. Das ist eine schnelle Plausibilitätsprüfung beim Debuggen eines Deployment, kein Ersatz für ein vollständiges Sicherheits-Audit.

Alles läuft lokal in Ihrem Browser ab: Die Header, die Sie einfügen und die Cookies, Tokens oder interne Hostnamen enthalten können, werden nirgendwo hochgeladen. Die Analyse verarbeitet sowohl Windows (CRLF) als auch Unix (LF) Zeilenumbrüche, toleriert veraltete Folgezeilen und stoppt bei der ersten Leerzeile — genau dort, wo der HTTP-Standard den Anfang des Body definiert — daher ist das Einfügen einer vollständigen Response mit angefügtem Body sicher.

Häufige Fragen

Funktioniert es sowohl mit Requests als auch mit Responses?
Ja. Es erkennt automatisch eine Request-Zeile (Methode, Ziel, HTTP-Version) oder eine Status-Zeile (HTTP-Version, Statuscode, Reason-Phrase) und fällt auf einfache Header-Zeilen zurück, wenn keine vorhanden ist.
Was genau bedeutet "Zusammengesetzte Header erweitern"?
Header, deren Wert wirklich eine Liste von Direktiven ist: Cache-Control und Permissions-Policy mit Kommas, Content-Security-Policy und Strict-Transport-Security mit Semikola. Jede Direktive wird zu einer separaten Zeile unter demselben Header-Namen.
Welche Sicherheits-Header werden geprüft?
Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy und Permissions-Policy — sechs häufig empfohlene Response-Header. Es zeigt nur an, welche fehlen; die Werte vorhandener Header werden nicht validiert.
Was passiert mit dem Body, wenn ich eine vollständige Response einfüge?
Nichts — er wird ignoriert. Die Analyse stoppt bei der ersten Leerzeile, wo HTTP-Header enden und der Body beginnt, daher ist das Einfügen einer vollständigen curl -i oder Browser-Erfassung sicher.
Werden meine eingefügten Header-Daten irgendwo hochgeladen?
Nein. Die Analyse läuft vollständig in Ihrem Browser ab — die Header, inklusive aller Cookies oder Tokens, verlassen Ihr Gerät niemals.