HTTP-Header-Parser — Request- und Response-Header, Zeile für Zeile dekodiert
HTTP-Header-Parser
Fügen Sie einen vollständigen HTTP-Request oder -Response ein — den Block, den curl -v ausgibt oder den das Netzwerk-Panel des Browsers anzeigt — und jede Header-Zeile wird dekodiert: der Name, der Wert, ein verständlicher Satz darüber, was er bewirkt, und das Dokument, das ihn definiert. Set-Cookie wird Attribut für Attribut zerlegt (Secure, HttpOnly, SameSite, Max-Age, Expires…), die Parameter von Content-Type und Accept werden aufgelöst, und der Block wird auf die klassischen strukturellen Probleme geprüft: veraltete gefaltete Zeilen, unzulässige Zeichen, doppelte Header und Header, die in die falsche Richtung gesendet wurden. Alles läuft in Ihrem Browser, und nichts wird hochgeladen.
Eingabe
Automatisch sieht die erste Zeile an: Eine Request-Zeile (GET /pfad HTTP/1.1) bedeutet Request, eine Statuszeile (HTTP/1.1 200 OK) bedeutet Response, alles andere wird als reiner Header-Block gelesen. Die anderen Auswahlmöglichkeiten erzwingen die Richtung, was ändert, welche Warnungen gelten.
Geparster Bericht
Noch nichts geparst. Fügen Sie oben einen Request- oder Response-Block ein und drücken Sie Header parsen, oder drücken Sie Beispiel für ein durchgerechnetes Beispiel.
Wo Sie einen lohnenden Block finden. Im Terminal gibt curl -v https://example.com/ 2>&1 den Request und die Response mit den Präfixen > und < aus — entfernen Sie diese und fügen Sie ein. curl -sI https://example.com/ liefert nur den Response-Header-Block. Im Browser öffnen Sie die Entwicklertools, den Reiter Netzwerk, laden neu, wählen die Dokumentanfrage und verwenden Kopieren → Response-Header kopieren; für die Request-Seite verwenden Sie Als cURL kopieren und lesen die Flags. Ein reiner Block aus Name: Wert-Zeilen ohne Startzeile wird ebenfalls geparst — die Richtungsprüfungen werden dann gelockert.
Selbsttest Führt den Parser gegen feste Blöcke erneut aus: Richtungserkennung, beide Beispielgruppen, jede Set-Cookie-Attributregel (SameSite=None ohne Secure, ein nicht-numerisches Max-Age, ein fehlerhaftes Expires, ein unbekanntes Attribut, ein Cookie ohne Gleichheitszeichen), obs-fold-Zusammenführung, unzulässige Feldnamen, doppelte Header, Richtungsabweichungen und die Negativpfade. Nichts wird irgendwohin gesendet.
Was ist ein HTTP-Header?
In einem Satz: Eine HTTP-Nachricht ist eine Startzeile, ein Block aus Name: Wert-Zeilen (den Headern), eine leere Zeile und ein optionaler Body — die Header tragen alles über die Nachricht außer dem Body selbst: wer sie gesendet hat, was sie akzeptieren kann, wie sie zwischengespeichert wird, wie sie authentifiziert wird und was der Absender zurückerhalten möchte.
Die vier Familien
Familie
Reist weiter
Beispiele
Beantwortet die Frage
Request-Header
Client → Server
Host, Accept, Cookie, Referer, Authorization
was der Client will und als wer er sich ausgibt
Response-Header
Server → Client
Location, Server, Set-Cookie, Retry-After
was der Server getan hat und was er im Gegenzug verlangt
in welchem Format der Body vorliegt und welche Kopie es ist
Steuer-Header
beides, über die Verbindung
Cache-Control, Connection, Via, Transfer-Encoding
wie die Nachricht und die Verbindung unterwegs behandelt werden
Manche Header sind eindeutig einseitig: If-None-Match ergibt nur im Request Sinn, Set-Cookie nur in der Response. In die falsche Richtung zu parsen ist einer der klassischen Copy-Paste-Debugging-Fehler, weshalb diese Seite ihn markiert.
Die Grammatik einer Header-Zeile
RFC 9110 definiert eine Feldzeile als field-name ":" OWS field-value OWS — ein Name nur aus Token-Zeichen (Buchstaben, Ziffern und !#$%&'*+-.^_`|~), ein Doppelpunkt mit keinem Leerzeichen davor, und ein Wert aus sichtbaren Zeichen, Leerzeichen und Tabs. Header-Namen sind nicht case-sensitiv (content-type entspricht Content-Type); Werte sind fast immer case-sensitiv. Eine Zeile, die mit einem Leerzeichen oder Tab beginnt, setzte früher den vorherigen Header fort — obs-fold, seit 2014 veraltet: Ein Proxy, der sie auffaltet, kann die Bedeutung des Headers ändern, daher fügt der Parser sie hier zusammen, warnt Sie aber, dass sie existiert.
Häufige Fehler
Dem X-Forwarded-For vertrauen. Es wird von jedem Proxy auf dem Weg hinzugefügt, und ein Client kann den ersten Hop fälschen. Es sagt Ihnen, was eine Kette von Proxys behauptet, nicht wer verbunden ist; behandeln Sie es als Hinweis und bevorzugen Sie einen Proxy, den Sie kontrollieren, der es überschreibt.
Nur die Response-Header lesen. Die Hälfte der interessanten Fehler (ein doppeltes Accept, ein fehlendes Host, ein Authorization-Header an den falschen Host) steckt im Request, den der Browser standardmäßig verbirgt. Verwenden Sie Als cURL kopieren, um Ihre eigenen zu sehen.
Zusammenführen von Set-Cookie-Zeilen. Die meisten doppelten Header dürfen mit Kommas kombiniert werden — Set-Cookie nicht, weil das Komma im Wert selbst vorkommen kann. Browser behandeln jede Zeile als eigenes Cookie.
Erwarten, dass Content-Length die Body-Größe ist, die Sie geschrieben haben. Sie ist die Größe nach Anwendung von Content-Encoding und nur, wenn die Nachricht nicht chunked ist; eine Antwort mit Transfer-Encoding: chunked hat keine aussagekräftige einzelne Länge.
Header nach dem Präfix X- beurteilen. Die Konvention ist mit RFC 6648 gestorben: X-Forwarded-For und X-Content-Type-Options sind dauerhafte De-facto-Standards, während viele Nicht-X-Header experimentell sind. Beurteilen Sie nach dem definierenden Dokument, nicht nach dem Präfix.
FAQ
Ist es sicher, Header hier einzufügen? Das Parsen erfolgt vollständig in Ihrem Browser, und nichts wird hochgeladen. Trotzdem ist ein kopierter Header-Block ein Fingerabdruck: Cookies, Authorization-Header und der genaue User-Agent können Sie zusammen identifizieren. Parsen Sie daher nur Blöcke, die Sie einem Kollegen auch zeigen würden.
Warum zeigt mein Browser Header wie :status, die diese Seite als Fehler meldet? Das sind Pseudo-Header von HTTP/2 und HTTP/3 — die binären Rahmenschichten ersetzen die Startzeile und Host durch Pseudofelder. Diese Seite parst den klassischen HTTP/1.1-Klartext; Pseudo-Header enthalten dieselbe Information, nachdem das Protokoll sie übersetzt hat.
Was ist aus X-XSS-Protection geworden? Es ist veraltet: Der Auditor, den es steuerte, verursachte eigene Sicherheitsfehler, und Browser haben ihn entfernt. Seine Aufgabe übernimmt eine Content-Security-Policy — erstellen Sie eine mit dem CSP-Generator und prüfen Sie die gesamte Menge auf dem Prüfer für Sicherheits-Header.
Wie wird ein Set-Cookie-Attribut geprüft? Gegen RFC 6265: Namen und Werte werden am ersten Gleichheitszeichen getrennt, Attribute nach dem ersten Semikolon; Expires muss ein Datum im Cookie-Format sein, Max-Age Ziffern, SameSite einer der Werte Strict/Lax/None — und None ohne Secure wird von aktuellen Browsern abgelehnt, daher wird es hervorgehoben.
Kann ich nur eine Liste von Header-Zeilen parsen? Ja — wählen Sie Nur Header-Block und fügen Sie ohne Startzeile ein. Die Richtungsprüfungen werden gelockert; alles andere (Struktur, Set-Cookie, Parameter) läuft weiterhin.
