HTTP-Header: Wissenswertes über HTTP-Kopfzeilen

Beispiel-Clientanfrage (Request)

Ein Beispiel für einen HTTP-Header: Wir möchten eine Webseite ansteuern und geben eine URL ein. Der Browser baut eine (TCP-)Verbindung zum Server auf und sendet ihm eine Anfrage (Request), genauer eine HTTP-GET-Anforderung:

 

GET  /beispielseite.html HTTP/1.1
HOST: beispieldomain.tld
Accept-Language: de
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 125_06_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/125.06 Mobile/15E148 Safari/604.1

 

Übersetzung: Der Server mit dem Hostnamen beispieldomain.tld möge die Ressource beispielseite.html zurücksenden, möglichst in deutscher Sprache und optimiert für Safari auf dem iPhone..

HTTP-Nachrichten beginnen immer aus einer Startzeile, die die Anfragemethode (z. B. GET, POST etc.) oder bei Antworten den Statuscode enthält (z. B. „200 OK“). Es folgen optional eine oder mehrere Kopfzeilen, eine Leerzeile, die das Ende der Header-Felder anzeigt, und gegebenenfalls ein Nachrichten-Body. GET-Requests enthalten keinen Body; in Antwortnachrichten enthält der Body die jeweils angeforderte Ressource, also etwa eine HTML-, PHP-, CSS- oder Mediendatei. 

HTTP-Kopfzeilen für Anfragen: Request Header

„Host“, „Accept-Language“ und „User-Agent“ im obigen Beispiel sind HTTP-Kopfzeilen (also HTTP-Header-Felder, oft auch nur „Header“ genannt). Kopfzeilen übermitteln dem anderen Server diverse Informationen, die für die Kommunikation und die Übertragung der angeforderten Ressource wichtig sind. Sie bestehen aus Schlüssel-Wert-Paaren, die durch Doppelpunkt getrennt werden.

Bei Anfragen enthalten die Kopfzeilen beispielsweise Informationen zu Host und Client sowie zur angeforderten Ressource. Einige Beispiele:

Accept: Inhaltstypen, die der Client akzeptiert. Beispiel:

Accept: image/* (akzeptiert verschiedene Subtypen des MIME-Type „Image“)

Accept-Charset: akzeptierte Zeichensätze; es gibt noch weitere Accept-Headerfelder, z. B. für komprimierte Formate (Accept-Encoding) oder Sprachen (Accept-Language):

Accept-Charset: utf-8 (akzeptiert die Standardkodierung 8-Bit-Unicode)

Cache-Control: Festlegung von Caching-Optionen (mehr dazu gleich); gibt es auch für Antworten:

Cache-Control: no-cache (die Ressource wird neu vom Server geladen, auch wenn sie im Cache und noch nicht abgelaufen ist)

Date: Datum und Uhrzeit der Anfrage; auch für Antworten:

Date: Mon, 05 Sep 2022 15:42:59 GMT

Referer (sic): kennzeichnet die Webseite, von der die Anfrage ausgeht, insbesondere bei Links:

Referer: beispiel.de

User-Agent: Infos zu Anwendung, Betriebssystem, Hersteller und/oder Version der anfragenden Browsers o. a. Programms:

User-Agent: Mozilla/5.0 (Windows NT 13.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0 (Chrome auf Windows 11)

10% Rabatt auf alle DF Produkte

Jetzt 2-Jahre Laufzeit wählen!

Host Header

In der zweiten Zeile des obigen Beispiel-Requests erscheint der „Host“-Header mit dem Domainnamen des Servers. Im Gegensatz zu den meisten anderen HTTP-Headerfeldern ist dieser seit HTTP/1.1 zwingend vorgeschrieben. Fehlt er, muss der Server den Status „400 Bad Request“ zurückmelden. Hintergrund: Der Host Header kann zur namensbasierten Unterscheidung virtueller Hosts genutzt werden, sodass Websites mit unterschiedlichen Domainnamen unter einer gemeinsamen IP-Adresse betrieben werden können (wichtig vor allem bei den immer knapper werdenden IPv4-Adressen). Beispiel:

Host: df.eu

Wie funktionieren Host-Header und was bewirken sie?

Host-Header sind ein wesentlicher Bestandteil von HTTP-Anfragen und dienen dazu, den genauen Hostnamen oder die Domain der angeforderten Ressource auf einem Webserver zu spezifizieren. Dies ist besonders wichtig in Umgebungen mit virtuellem Hosting, wo ein einzelner Server mehrere Domains oder Subdomains hostet. Der Host-Header ermöglicht es dem Server, die richtige Webseite auszuliefern, indem er die Anfrage basierend auf dem angegebenen Hostnamen korrekt zuordnet. In HTTP/1.1 ist der Host-Header obligatorisch; ohne ihn kann der Server nicht bestimmen, welche spezifische Webseite angefordert wird, was zu Fehlern in der Anfrageverarbeitung führen kann.

Was sind Content-Type-Header und wie werden sie eingesetzt?

Content-Type-Header sind HTTP-Header, die in HTTP-Anfragen und -Antworten verwendet werden, um den Medientyp (MIME-Typ) des Inhalts zu definieren. 

In HTTP-Antworten: Ein Server verwendet den Content-Type-Header, um dem Client mitzuteilen, welchen Typ von Daten er gerade sendet (z.B. `text/html` für HTML-Dokumente, `application/json` für JSON-Daten).

In HTTP-Anfragen: Bei Anfragen, die Daten an den Server senden (wie POST oder PUT), gibt der Content-Type-Header im Request den Typ der gesendeten Daten an, damit der Server weiß, wie er sie verarbeiten soll.

Die korrekte Verwendung des Content-Type-Headers ist für die Funktionalität von Webanwendungen wesentlich, da sie die ordnungsgemäße Darstellung und Verarbeitung von Inhalten auf verschiedenen Plattformen und Anwendungen ermöglicht.

Beispiel-Serverantwort (Response)

Die Antwort des Servers auf die oben genannte Beispielanfrage könnte so aussehen:

 

HTTP/1.1 200 OK
Date: Sat, 17 Sep 2022 10:45:13 GMT
Server: Apache
Last-Modified: Wed, 3 Aug 2022 11:00:44 GMT
Accept-Ranges: bytes
Content-Length: 16209
Content-Type: text/html
Cache-Control: maxe-age=180
eTag: "x26e3"
Set-Cookie: id=dlvbhd32; Expires=Tue, 13 Oct 2020 00:00:00 GMT
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//DE ">
<html>
… [der Rest der 16209 Bytes von beispielseite.htm]
</html>

 

Eine gute Nachricht: Die Anfrage war erfolgreich. Das signalisiert der Server in der Antwortzeile mit dem Statuscode „200 OK“. Nach den Kopfzeilen folgt beginnend mit <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//DE "> die Nutzlast, die angeforderte HTML-Seite beispielseite.html.

HTTP-Kopfzeilen für Antworten: Response Header

Alles im Beispiel von „Date: …“ bis „Set-Cookie: …“ sind wieder Kopfzeilen. Im Beispiel zeigt der Server dem Client u. a. mit „cache-control: max-age=180“ an, dass dieser bei erneutem Bedarf die lokal gespeicherte Webseite drei Minuten (180 Sekunden lang) verwenden kann, ohne sie noch einmal vom Server zu laden. Außerdem versucht der Server ein Cookie zu setzen, das bis zum 17. Oktober 2022 gültig sein soll. Hier ein paar weitere Beispiele für Response Header nach einem GET-Request:

Access-Control-Allow-Origin: erlaubt Cross-Origin Resource Sharing (als Ausnahme von der Same-Origin-Policy für Browser) mit Code bestimmter Herkunft. Beispiel:

Access-Control-Allow-Origin: beispielseite.de

Connection: vom Server bevorzugte Verbindungsarten; gibt es auch für Anfragen. Verboten in HTTP/2:

Connection: Keep-Alive

Keep-Alive: Festlegung von Zeitlimit und maximaler Zahl von Anfragen bei Keep-Alive-Verbindungen (siehe oben). Verboten in HTTP/2:

Keep-Alive: timeout=5, max=997

Content-Encoding: Wie wurde die Nutzlast kodiert (= komprimiert) und in welcher Reihenfolge:

Content-Encoding: deflate, gzip

Content-Type: MIME-Typ der angeforderten Datei (bei Text-Typen inkl. Zeichensatz); auch für Anfragen wie POST oder PUT:

Content-Type: text/html; charset=utf-8

Etag: Der ETag (Entity Tag) identifiziert eine bestimmte Version einer Ressource, um effizienteres Caching zu ermöglichen:

Etag: "675b0f612a9199f722e3a621a"

Last-Modified: Zeit, zu der die Ressource zuletzt geändert wurde; dient ebenfalls der Versionsunterscheidung, wenn kein ETag vorliegt:

Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT

Server: Angaben zur Software des Servers, der die Antwort erzeugt hat:

Server: Apache/2.4.1 (Unix)

Hinweis: Da in HTTP-Antwort-Headern wie „Server“ potenziell sicherheitskritische Angaben übermittelt werden können, sollten Sie hier Vorsicht walten lassen und keine zu detaillierten Informationen preisgeben.

Wie beeinflussen HTTP-Header die Sicherheit einer Webseite?

HTTP-Header spielen eine entscheidende Rolle bei der Sicherheit einer Webseite, indem sie verschiedene Sicherheitsrichtlinien und -kontrollen bereitstellen:

• Content Security Policy (CSP): CSP-Header helfen, Cross-Site Scripting (XSS) und Dateninjektionsangriffe zu verhindern. Sie erlauben Webseitenbetreibern, die Quellen zu definieren, von denen Inhalte geladen werden dürfen, und blockieren damit potenziell schädliche Skripte.
• HTTP Strict Transport Security (HSTS): Der HSTS-Header zwingt Browser dazu, ausschließlich sichere HTTPS-Verbindungen zur Webseite aufzubauen, was die Risiken von Man-in-the-Middle-Angriffen reduziert.
• X-Content-Type-Options: Dieser Header verhindert, dass der Browser MIME-Typen von Ressourcen gegenüber dem vom Server deklarierten Typ „snifft“. Das Setzen auf `nosniff` verhindert, dass der Browser fehlerhaft spekulierte MIME-Typen ausführt, was die Sicherheit erhöht.
• X-Frame-Options: Durch diesen Header können Webseitenbetreiber steuern, ob ihre Inhalte in `<iframe>`, `<object>` oder in anderen Elementen eingebettet werden dürfen. Dies hilft, Clickjacking-Angriffe zu verhindern.
• Set-Cookie-Header (Secure und HttpOnly Flags): Wenn Cookies über den `Set-Cookie`-Header gesetzt werden, verbessern die Flags `Secure` und `HttpOnly` die Sicherheit. `Secure` sorgt dafür, dass Cookies nur über HTTPS gesendet werden, und `HttpOnly` verhindert, dass JavaScript auf die Cookie-Daten zugreift.
• Cross-Origin Resource Sharing (CORS): CORS-Header kontrollieren, wie Ressourcen von einer anderen Domain als der Ursprungsdomain einer Webseite verwendet werden können. Dies schützt vor unerwünschten Cross-Site-Anfragen.
• Public Key Pinning Extension for HTTP (HPKP): (Nicht mehr weit verbreitet) Dieser Header ermöglichte es Webseiten, Hashes von öffentlichen Schlüsseln anzugeben, die vom Browser zur Validierung von HTTPS-Zertifikaten verwendet werden sollten. Dies schützte vor bestimmten Arten von Man-in-the-Middle-Angriffen, birgt aber auch Risiken.
• Feature-Policy: Mit diesem Header können Webseitenbetreiber bestimmte Browserfunktionen und -APIs deaktivieren oder einschränken, die missbraucht werden könnten, um die Sicherheit oder Privatsphäre der Nutzer zu gefährden.

Die richtige Konfiguration und der Einsatz dieser Header tragen wesentlich zur Abwehr von Webangriffen und zur Sicherung der Datenintegrität und Benutzerprivatsphäre bei. 

Das alles können Sie mit Kopfzeilen tun

Mit Kopfzeilen kann der Server dem Client eine Vielzahl von Informationen übermitteln, aber auch diverse Funktionen anstoßen, zum Beispiel Sicherheitsfunktionen des Browsers aktivieren, das Caching durch Browser oder Proxies steuern oder Cookies setzen. Damit werden HTTP-Kopfzeilen zu einem mächtigen Werkzeug für Entwickler und Webmaster.

Header-Felder unterteilen sich in reine Anfrage- bzw. Antwort-Kopfzeilen sowie sogenannte allgemeine Kopfzeilen (General Header Fields) und „Entity“-Kopfzeilen, die sowohl in Anfragen als auch in Antworten Verwendung finden können. Allgemeine Kopfzeilen liefern Informationen über die Nachricht im Ganzen. Dazu zählen zum Beispiel die schon erwähnten „Cache-Control“-Zeilen, aber auch etwa „Date“, „Transfer-Encoding“ (zur Absicherung der Nachricht) oder „Connection“ (zur Steuerung der Verbindung).

Entity-Kopfzeilen beziehen sich dagegen auf die „Entity“, also den „Inhalt“ der Nachricht einer Nachricht. Das können etwa eine Datei in einer Antwortnachricht oder Formulardaten in einem POST-Request sein. Gibt es wie bei GET-Requests keinen Body, beziehen sie sich auf die angeforderte Ressource.  „Content-Length“ und „Content-Type“ sind uns oben schon begegnet, andere sind „Expires“, „Last-Modified“ oder die Kopfzeile „Content-MD5“, mit der ein MD5-Hash mitgeschickt werden kann, um dem Empfänger eine Integritätsprüfung der Nachricht zu erlauben. Eine Liste aller HTTP-Header finden Sie bei Mozillas MDN.

Hier ein paar Beispiele zur Arbeit mit Kopfzeilen:

Cache-Control

Eine effiziente Nutzung des Browser-Caches beschleunigt den Seitenaufbau und spart Bandbreite. Seitenbetreiber müssen aber verhindern, dass der Browser veraltete Inhalte anzeigt. Mit HTTP-Kopfzeilen können sie z. B. Caching-Optionen festlegen (Cache-Control), Versionen einer Ressource unterscheiden (Etag, Last-Modified) oder ein Verfallsdatum für Ressourcen festlegen (Expires, Cache-Control: max-age). Mehr Informationen zu diesem spannenden Thema finden Sie hier.

Autorisierung

Eine wichtige Antwort-Kopfzeile ist „WWW-Authenticate“. Damit zeigt der Server (in einer Nachricht mit Status 401 „Unauthorized“) einem Client an, dass zum Zugriff auf die angeforderte Ressource Anmeldeinformationen erforderlich sind. Diese kann der Client in der Anfrage-Kopfzeile „Authorization“ übermitteln.

Cookies

Eine weitere elementare Funktion, die über Header-Felder realisiert wird, sind Cookies. Denn HTTP ist ein sogenanntes zustandsloses Protokoll – ohne Cookies wäre es nicht möglich, verschiedene Nachrichten einem bestimmten Benutzer oder Anwendungszustand (zum Beispiel Warenkorb) zuzuordnen. Der Server setzt Cookies mit der Kopfzeile „Set-Cookie: ...“; der Client sendet bei erneuten Anforderungen das Cookie per „Cookie: ...“ mit.

Benutzerkonfigurierte Kopfzeilen

Es ist übrigens auch möglich, eigene Kopfzeilen zu definieren – zum Beispiel für Informationszwecke, bestimmte serverseitige Anwendungen oder die Fehlersuche. In Entwicklerkreisen hat sich eingebürgert, Custom-Header-Felder mit „X-...“ zu kennzeichnen; nötig ist das nicht.

Beispielsweise nutzt der Website-Security- und CDN-Anbieter Sucuri die Kopfzeile „x-sucuri-cache“. Daran kann der Client erkennen, ob eine angeforderte Ressource direkt von einem nahe gelegenen CDN-Proxy-Server geladen werden konnte („x-sucuri-cache: HIT“) oder vom Originalserver kam („x-sucuri-cache: MISS“).

Auch einige Security-Kopfzeilen wie „X-XSS-Protection“, „X-Content-Type-Options“ oder „X-Frame-Options“ sind nicht standardisiert, sondern wurden von Browserherstellern eingeführt (und werden daher u. U. nicht von allen Browsern unterstützt).Wer sich HTTP-Header mit ihren Kopfzeilen live ansehen möchte, kann dazu die Developer-Tools seines Browsers nutzen. Neben den schon beschriebenen Kopfzeilen werden Sie dabei wahrscheinlich auch die eine oder andere Überraschung erleben, weil die Webentwickler den Header zum alternativen Infokanal umfunktionieren. So findet man beispielsweise „X-Han: Shot first“ (von nextthing.org), „x-nananana: Batcache“ (von automattic.com) oder gleich mal ein Jobangebot:

 

x-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.

 

So konfigurieren Sie Ihre HTTP-Kopfzeilen selbst

Zum Abschluss noch ein kurzer Überblick, wie Sie HTTP-Header-Felder bei Apache, Nginx und Typo3 einrichten können. 

Bei Apache werden Kopfzeilen über das Modul mod_headers mit der Direktive Header konfiguriert (in der httpd.conf oder per .htaccess-Datei). So erzeugt

 

Header set X-Mein-Custom-Header "Wert"

 

die Kopfzeile 

 

X-Mein-Custom-Header: Wert

 

Bei Nginx erledigt dasselbe der folgende Eintrag in die Konfigurationsdatei nginx.conf (Kontext: http, server oder location):

 

add_header X-Mein-Custom-Header Wert;

 

In Typo3 gibt es je nach Kopfzeile(n) verschiedene Möglichkeiten. Folgendermaßen aktivieren Sie per TypoScript das Browser-Caching:

 

config.sendCacheHeaders = 1

 

Für „content-length“ steht „config.enableContentLengthHeader“ zur Verfügung, für weitere Header „config.additionalHeaders“ (anzugeben als numerisches Array): 

 

config.additionalHeaders.10 {
header = X-Mein-Custom-Header1: Wert1
}

 

Wie Sie sehen, eröffnen HTTP-Kopfzeilen viele Möglichkeiten, die wir hier nur anreißen konnten. Deshalb gibt es eigene Beiträge zu den Themen „Cache-Control“ und „Webserver-Security verbessern“. Schauen Sie gern mal vorbei!

Können HTTP-Header zur Fehlerbehebung in Webanwendungen verwendet werden?

HTTP-Header können effektiv zur Fehlerbehebung in Webanwendungen verwendet werden. Hier sind einige Aspekte, wie sie dabei helfen können:

• Statuscodes identifizieren: HTTP-Statuscodes in den Antwort-Headern (wie 404 für nicht gefunden, 500 für Serverfehler) geben schnell Aufschluss über die Art des Problems.
• Cache-Verhalten überprüfen: Header wie `Cache-Control` und `Expires` helfen zu verstehen, wie Ressourcen gecacht werden. Probleme mit veralteten Inhalten können oft auf Caching-Einstellungen zurückgeführt werden.
• Session- und Authentifizierungsinformationen: Header wie `Set-Cookie` (für Session-IDs) oder spezielle Authentifizierungs-Header helfen dabei, den Authentifizierungsfluss und Session-Management-Probleme zu debuggen.
• CORS-Probleme identifizieren: CORS-Probleme, die zu Zugriffsfehlern führen, können durch Überprüfung der `Access-Control-Allow-Origin`-Header identifiziert werden.
• Performance-Analyse: Header wie `Content-Encoding` (zeigt Komprimierung an) und `Transfer-Encoding` können bei der Analyse von Performance-Problemen hilfreich sein.
• SSL/TLS-Konfigurationsprobleme: Header im Zusammenhang mit Sicherheitsprotokollen (wie HSTS) helfen bei der Identifizierung von Konfigurationsproblemen in SSL/TLS.
• Anfragedetails überprüfen: Benutzerdefinierte Header oder Standard-Request-Header wie `User-Agent` oder `Accept` können wertvolle Informationen über die Anfrage liefern, die für die Fehlersuche nützlich sind.
• Redirect-Probleme verfolgen: Die `Location`-Header in 3xx-Antworten helfen bei der Nachverfolgung von Umleitungsproblemen.

Tools wie Browser-Entwicklertools, cURL oder spezialisierte Software können helfen, die HTTP-Header in Anfragen und Antworten zu analysieren.