Tipps & Tutorials

HTTP-Header: Wissenswertes über HTTP-Kopfzeilen


Veröffentlicht am 07.11.2022 von DomainFactory

(Update) Wenn HTTP die Sprache ist, die Systeme und Geräte im Internet zur Verständigung nutzen, dann sind HTTP-Nachrichten Sätze und Wörter, die sie dabei austauschen. Doch das, was uns interessiert – Texte, Bilder, Videos etc. – ist dabei „nur“ die Nutzlast von Server-Antwortnachrichten. Die Systeme selbst interessiert mehr, was genau andere Systeme von ihnen wollen, wenn sie ihnen eine Nachricht schicken. Und das finden sie in den Headern von Client-Anfragen (Requests) und Server-Antworten (Response).

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)

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

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.

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: httpserver 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!

Der Autor:


Als Qualitätsanbieter überzeugen wir mit HighEnd-Technologie und umfassenden Serviceleistungen. Mit mehr als 1,3 Millionen verwalteten Domainnamen gehören wir zu den größten Webhosting-Unternehmen im deutschsprachigen Raum.