HTTP-Header-Suche

Die HTTP-Header-Suche ist ein kostenloses Tool, das alle HTTP-Antwort-Header abruft, die eine URL bei einer typischen GET-Anfrage zurückgibt.

Was sind HTTP-Antwort-Header?

HTTP-Antwort-Header sind Metadaten, die ein Webserver vor dem eigentlichen Antwortinhalt sendet, beispielsweise vor einer HTML-Seite, einem Bild oder einem JSON-Dokument. Sie teilen dem Client mit, wie er die Antwort interpretieren, zwischenspeichern, weiterleiten oder absichern soll.

Eine HTTP/1.x-Antwort beginnt normalerweise mit einer HTTP-Statuszeile, auf die die Header folgen. Bei HTTP/2 und HTTP/3 wird der entsprechende Status im Pseudo-Header :status übermittelt. Technisch gesehen ist die HTTP/1.x-Statuszeile von den Headern getrennt. Da sie jedoch erkennen lässt, ob die Anfrage erfolgreich war, wird sie häufig zusammen mit ihnen angezeigt. Der Status 200 bedeutet etwa, dass die Ressource zurückgegeben wurde. 301 oder 302 kennzeichnet eine Weiterleitung, 404 bedeutet, dass die Ressource nicht gefunden wurde, und 500 weist auf einen serverseitigen Fehler hin.

Header können vom Ursprungsserver, von einem Reverse-Proxy oder von einem Content Delivery Network wie Cloudflare stammen. Beim Durchlaufen dieser Systeme werden mitunter Header hinzugefügt oder entfernt. Das Ergebnis kann daher mehr als nur die Anwendung beschreiben, die die Seite erzeugt hat.

Wie prüfe ich die HTTP-Header einer URL?

Gib die vollständige URL einschließlich des Schemas ein, zum Beispiel https://www.example.com/account. Das Tool sendet von seinem Server aus eine typische GET-Anfrage und zeigt die HTTP-Header an, die es von dieser URL empfängt.

Wenn du Antwort-Header genau vergleichen möchtest, verwende jeweils exakt die URL-Varianten, die du untersuchen willst. Die Header für http://example.com, https://example.com und https://www.example.com können sich unterscheiden, da jede Adresse eigene Weiterleitungen, Cache-Regeln und Servereinstellungen haben kann.

Auch die Syntax der URL beeinflusst die Anfrage:

• Leerzeichen sind als unverarbeitete URL-Zeichen nicht zulässig und müssen normalerweise prozentcodiert werden, in einem Pfad üblicherweise als %20.
• ? leitet den Abfrageteil ein. & und = werden häufig in formularähnlich codierten Abfragen verwendet, haben diese Funktion aber nicht in jeder Abfragezeichenfolge.
• Domainnamen mit Akzenten oder nichtlateinischen Zeichen werden mithilfe von IDNA verarbeitet und als ASCII-A-Labels dargestellt, die üblicherweise mit xn-- beginnen. Zeichen im Pfad werden dagegen in der Regel zunächst in UTF-8-Bytes umgewandelt und anschließend prozentcodiert.
• Ein mit # beginnendes Fragment wird vom Browser verarbeitet und nicht in der HTTP-Anfrage gesendet.
• Für die Länge einer URL gibt es keine allgemeingültige Obergrenze. Sehr lange URLs können von einem Server, Proxy oder einer Anwendung abgelehnt werden.

Wie lese ich das Ergebnis der HTTP-Header-Suche?

Prüfe vor allem die Header, die mit dem untersuchten Fehler zusammenhängen. Bei Headernamen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Ihre Werte können jedoch eine Syntax verwenden, bei der die Schreibweise relevant ist.

Andere Header können anwendungsspezifisch sein. So legt Access-Control-Allow-Origin fest, welche Ursprünge eine Antwort über ursprungsübergreifende Browseranfragen lesen dürfen. Ein Server-Header kann eine Software oder einen Proxy nennen, ist aber kein verlässlicher Nachweis für die zugrunde liegende Plattform. Administratoren können diesen Header ändern oder entfernen.

Typische Szenarien bei der Fehlersuche

Probleme mit Weiterleitungen sind ein häufiger Grund, Header zu untersuchen. Angenommen, https://example.com/old-page gibt den Status 301 zusammen mit Location: https://example.com/new-page zurück. Damit weist der Server den Client an, die neue Adresse aufzurufen. Wenn du jedes Ziel einzeln und wiederholt prüfst, kannst du eine Weiterleitungsschleife oder einen unerwarteten Wechsel zwischen HTTP und HTTPS erkennen.

Wird hinter Cloudflare oder einem anderen CDN eine veraltete Seite angezeigt, prüfe Cache-Control, Age, ETag sowie etwaige anbieterspezifische Cache-Header. Ein hoher Age-Wert bezeichnet das berechnete Alter der zwischengespeicherten Antwort und kann dabei auch die Zeit in vorgelagerten Caches einschließen. Er gibt nicht an, wie lange ein bestimmter Vermittler die Antwort gespeichert hat. Außerdem beweist er nicht, dass alle regionalen Caches dieselbe Version enthalten.

Wenn eine API in einem serverseitigen Skript funktioniert, im Browser aber fehlschlägt, untersuche Content-Type und die CORS-Antwort-Header einschließlich Access-Control-Allow-Origin. Gibt ein JSON-Endpunkt text/html zurück, liefert er möglicherweise tatsächlich eine Fehlerseite oder Anmeldemaske aus. Eine fehlende Berechtigung für ursprungsübergreifende Zugriffe kann dazu führen, dass der Browser den Zugriff blockiert, obwohl der Server den Status 200 zurückgegeben hat.

Header können auch bei einer scheinbar nicht erreichbaren Website weiterhelfen. Eine 503-Antwort deutet auf einen vorübergehenden Fehler des Servers oder eines vorgelagerten Systems hin. 404 bedeutet dagegen, dass der angeforderte Pfad nicht gefunden wurde. Allerdings lässt sich nicht jeder Fehler anhand von Headern diagnostizieren. Schlagen die DNS-Auflösung, die TCP-Verbindung oder die TLS-Aushandlung fehl, bevor eine HTTP-Antwort vorliegt, gibt es möglicherweise keine Antwort-Header, die du prüfen könntest. Mit Ping kannst du die Verbindung separat testen, während der HTTP/2 Prüfer die Protokollunterstützung prüft.

Warum kann ein korrektes Header-Ergebnis trotzdem falsch wirken?

Ein korrektes Ergebnis kann von der Anzeige in deinem Browser abweichen, weil Caches, DNS-Einträge und der Anfragekontext dazu führen können, dass die beiden Anfragen unterschiedliche Antworten erhalten. Diese Suche wird auf dem Server ausgeführt. Deshalb erreicht sie möglicherweise einen anderen CDN-Knoten oder löst einen kürzlich geänderten DNS-Eintrag früher oder später auf als dein lokales Netzwerk.

Browser senden außerdem eigene Cookies, akzeptierte Inhaltstypen, Spracheinstellungen und Cache-Validatoren. Eine WordPress-Seite kann für einen angemeldeten Benutzer daher andere Cache-Regeln zurückgeben als für eine anonyme Serveranfrage. Auch geografisches Routing und Systeme zur Bot-Erkennung können die Antwort abhängig vom Ursprungsnetzwerk oder von den Anfrage-Headern verändern.

Nach einer DNS-Änderung können zwischenspeichernde Resolver den vorherigen Eintrag weiterverwenden, bis dessen Gültigkeitsdauer abläuft. Sobald der Datenverkehr den neuen Server erreicht, können ein altes CDN-Objekt oder der Browser-Cache dennoch frühere Inhalte zurückgeben. Prüfe den aufgelösten Host separat, leere gegebenenfalls die Caches und vergleiche die exakte URL, statt davon auszugehen, dass alle Hostnamen dieselbe Konfiguration verwenden.

Häufig gestellte Fragen

Zeigt die Suche auch die Anfrage-Header an?

Nein. Sie ruft die Antwort-Header ab, die eine URL bei einer typischen GET-Anfrage zurückgibt. Anfrage-Header sind die an den Server gesendeten Metadaten. Um sie vollständig zu untersuchen, benötigst du separate Browser-Entwicklertools, Serverprotokolle oder einen Kommandozeilen-Client.

Bleiben die eingegebenen URLs vertraulich?

Die Suche wird auf dem Server ausgeführt. Deine Eingabe wird über HTTPS an diesen Server übertragen und nicht gespeichert. Gib keine URLs ein, die Passwörter, Zugriffstoken oder vertrauliche Abfrageparameter enthalten. Der Zielserver empfängt diese Werte ebenfalls, wenn die URL aufgerufen wird.

Können HTTP-Header eine Zertifikatswarnung erklären?

Für sich genommen normalerweise nicht. Die TLS-Verbindung wird hergestellt, bevor die HTTP-Antwort gesendet wird. Ein abgelaufenes Zertifikat, ein nicht übereinstimmender Hostname oder eine nicht vertrauenswürdige Zertifizierungsstelle kann daher verhindern, dass überhaupt Header zurückgegeben werden. Wenn die Browserwarnung erscheint, bevor die Seite geladen wird, prüfe das Zertifikat und seine Zertifikatskette separat.

Warum werden mehrere Set-Cookie-Header zurückgegeben?

Eine Antwort kann mehrere Cookies setzen, wobei jedes Cookie ein eigenes Set-Cookie-Feld verwendet. Fasse sie nicht wie eine durch Kommas getrennte Liste zusammen, da Ablaufdaten von Cookies selbst Kommas enthalten können. Prüfe Domain, Pfad und Sicherheitsattribute jedes Cookies einzeln.

Kann ich das Ergebnis mit curl vergleichen?

Ja. Ein Befehl wie curl -D - https://example.com/ -o /dev/null gibt die Antwort-Header aus und verwirft den Antwortinhalt. Unterschiedliche Curl-Versionen, Anfrage-Header, Weiterleitungseinstellungen und Netzwerkstandorte können zu abweichenden Ergebnissen führen. Gleiche diese Bedingungen daher ab, bevor du eine Abweichung als Serverfehler wertest.