HTTP Header Begriffserklärung und Definition

Der Hypertext-Transfer-Protokoll Header (HTTP Header) ist Teil einer Nachricht (Kommunikationseinheit) mit der Daten über das HTTP-Protokoll von einem Server an einen Webbrowser geschickt werden. Ein Protokoll besteht aus einer Reihe von Informationen über den Aufbau einer Nachricht, den Absender, den Empfänger, die Codierung und den Verbindungsaufbau. Diese werden über den Header übertragen. Nach dem Verbindungsaufbau zwischen Client und Server sendet der Client eine Anfrage (Request), die der Server beantwortet (Response). Erst wenn die Parameter zum Verbindungsaufbau abgeglichen sind, wird die angeforderte Datei gesendet und ist im Browser sichtbar. Der HTTP-Header setzt sich also zusammen aus den Informationen, die bei einer Anfrage und bei einer Antwort gesendet werden, wobei je nach Anfrage verschiedene Methoden (GET, POST, PUT) zur Verfügung stehen und je nach Methode bestimmte Informationen gesendet werden, um zu klären, ob und wie Daten zwischen Client und Server ausgetauscht werden können.
HTTP-Header-Request-Felder
HTTP-Header-Felder werden oft auch ungenau als HTTP-Header bezeichnet. Im Folgenden werden in alphabetischer Reihenfolge die wichtigsten Felder eines Header-Requests kurz benannt und beschrieben.
Accept
Das Accept-Feld gibt die Dateitypen der Anfrage an, die den Client erwarten. Das Feld besteht aus einem Haupt- und einem Untertyp, die durch einen Schrägstrich getrennt werden.
Beispiel: Accept: Text/HTML
Außerdem kann durch ein Semikolon getrennt auch die Qualität der gelieferten Datei angegeben werden. Da Browser heute fast alle sendefähigen Dateitypen interpretieren und darstellen können, wird im Accept-Feld meist die Angabe */* gemacht, die lediglich darüber formiert, dass es sich um jeden Dateityp handeln kann.
Accept-Charset
Das Accept-Charset-Feld gibt den Zeichensatz an, die im angeforderten Dokument zu finden sind. Werden mehrere Zeichensätze verwendet sind diese kommasepariert.
Beispiel: Accept-Charset: utf-8
Der Zeichensatz utf-8 wurde in diesem Beispiel absichtlich gewählt. Es handelt sich um die weit verbreitetste Codierung, die deckungsgleich mit dem Zeichensatz des ASCII ist. Mit dieser Codierung wird sichergestellt, dass alle Zeichen und Sonderzeichen ausgeschrieben werden können und dennoch richtig dargestellt werden können.
Accept-Encoding
Das Accept-Encoding-Feld gibt an, welche Codierungsverfahren der Client versteht. Üblicherweise werden die Verfahren gzip, compress oder deflate verwendet.
Beispiel: Accept-Encoding: gzip
Wird mehr als ein Verfahren getrennt, werden diese kommasepariert. Auch hier kann zusätzlich ein Qualitätsfaktor angegeben werden.
Accept-Language
Das Accept-Language-Feld informiert den Server darüber, welche Sprachen der Client bevorzugt. Mehrere Angaben werden auch hier kommasepariert.
Beispiel: Accept-Language: de
Autorization
Das Authorization-Feld authentifiziert den Client beim Server, sofern dies erforderlich ist. Benutzername und Passwort werden durch einen Doppelpunkt voneinander getrennt.
Beispiel: Authorization: BASIC SFRNTFdvcmxk:OkludGVybmV0
Das Wort BASIC gibt das Schema an, nach dem die Zeichenfolge verschlüsselt wurde.
Cookie
Das Cookie-Feld ist kein offizieller HTTP-Header-Wert. Es wird aber sehr oft verwendet, um bei einen erneuten Seitenaufruf den Nutzer identifizieren zu können. Das Feld besteht aus einem oder mehreren kommaseparierten Namen.
Beispiel: Cookie: name=cookie
Expect
Das Expect-Feld wird eher selten verwendet. Es dient dazu eine „Erwartung“ auszudrücken und verwendet hierzu den Wert 100-bis continue oder einen Text. Mehrere Parameter können durch Semikolon getrennt werden.
From
Das From-Feld enthält die E-Mail-Adresse des Clients.
Beispiel: From: name@domain.de
Host
Das Hostfeld gibt den Namen des Servers an, von aus eine Datei abgerufen werden soll. Dieser Wert ist HTTP 1.0 optional und bei HTTP 1.1 Pflicht. Er dient dazu, bei Servern mit mehreren Hostnamen die richtige Datei zu finden.
Beispiel: Host: www.beispiel.de:1234
If-Match
Das IF-Match Field gibt dem Server an nur eine Datei zu senden, die zum Entity-Tag. Wird ein Stern * angegeben, dann sind alle Dateien erwünscht. Mehrere Werte werden auch hier durch Kommas getrennt.
If-Modified-Since
Das If-Modified-Since-Feld befiehlt dem Server eine Datei nur dann zu senden, wenn sich ihr Inhalt seit dem angegebenen Datum verändert hat.
If-Modified-Since: Tue, 07 Apr 2004 23:24:25 GMT
If-None-Match
Das If-None-Match-Feld macht das Gegenteil des If-Match-Feldes. Es teilt dem Server mit, die Datei nur dann zu senden, wenn sie dem angegebenen Entity-Feld nicht entspricht. Auch hier werden mehrere Werte mit Kommas getrennt.
Beispiel: If-None-Match: „ga-j647d“
If-Range
Das If-Range-Feld dient der Zwischenspeicherung von Dateien und wird in Verbindung mit dem Range-Header-Feld verwendet. Es weist den Server an, nur die fehlenden Teile einer Datei zu senden, wenn sich die Datei nicht geändert hat. Sollte die Datei verändert worden sein, dann soll statt eines Teils die ganze Datei geschickt werden.
Beispiel: If-Range: Tue, 09 Apr 2012 23:33:25 GMT
If-Unmodified-Since
Das If-Unmodified-Since-Feld teilt dem Server mit, eine Datei nur dann zu senden, wenn sie seit dem als Wert angegebenen Datum nicht verändert wurde.
Beispiel: If-Unmodified-Since: Tue, 12 Apr 2011 23:25:28 GMT
Max-Forwards
Das Max-Forwards-Feld kommt nur bei TRACE und Options Anfragen (s. HTTP) vor. Als Wert wird eine Zahl angegeben, die den Proxy-Servern mitteilt, wie oft eine Nachricht maximal weitergeleitet werden darf. Wenn eine Nachricht mit diesem Feld bei einem Proxy-Server eintrifft, dann setzt dieser den Wert um 1 herab. Wenn der Wert null beträgt, dann leitet der Proxy die Nachricht an den Client zurück.
Beispiel: Max-Forwards: 5
Proxy-Authorization
Das Feld Proxy-Authorization dient der Authentifizierung eines Clients bei einem Proxy. Auch hier wird der Zeichenfolge das Verfahren zur Codierung vorangestellt.
Beispiel: Proxy-Authorization: BASIC SGRMTDdvcnxlPklrdHVycmVP
Range
Mit dem Range-Feld werden ein oder mehrere Bereiche einer Datei angefordert, die der Client noch benötigt. Als Bereichsangabe wird ein sogenannter Byte-Index angegeben. Mehrere Angaben werden durch Kommas getrennt.
Beispiel: Range: bytes=50-99,200-250
Referer
Das Referer-Feld enthält die URL von dem aus auf die angeforderte Datei verwiesen wird. Als Wert kann eine relative oder absolute URL angegeben werden.
Beispiel: Referer: http://www.beispielname.de
TE
Im TE-Feld wird angegeben, welche Codierungsverfahren der Client für die Anfrage zulässt.
Beispiel:TE: gzip;q=0.9
User-Agent
Mit dem User-Agent-Feld kann der Client den Header über sich selbst informieren. Als Wert kann hier der Produktname des Browsers angegeben werden.
Beispiel: User-Agent: Mozilla/3.1
HTTP-Header-Response-Felder
HTTP-Header-Felder werden oft auch ungenau als HTTP-Header bezeichnet. Im folgenden werden in alphabetischer Reihenfolge die wichtigsten Felder eines Header-Response beschrieben.
Accept-Ranges
Accept-Ranges-Feld gibt der Server dem Client zu verstehen, dass er Anfragen als Sequenz zulässt. Es kann die Werte bytes für einen Byte-Range oder den Wert none enthalten, wenn keiner Ranges erlaubt sind.
Age
Der Age-Feld gibt das Alter der angeforderten Datei in Sekunden an.
Beispiel: Age: 1234
ETag
Das Etag-Feld gibt dem Client eine eindeutige Bezeichnung der aufgerufenen Datei an, die vom Server verwendet wird, um die Datei eindeutig wiederzufinden. Sie kann vom Client zusammen mit den Feldern If-Match, If-None-Match und If-Range verwendet werden.
Beispiel: ETag: „hag735m“
Location
Mithilfe des Location Felds gibt der Server dem Client die neue Position eines Dokuments an, falls dieses umgezogen ist. Als Wert wird eine absolute URL angegeben.
Beispiel: Location: http://www.domain.tld
Proxy-Authenticate
Das Proxy-Authenticate-Feld teilt dem Client mit, dass der Proxy eine Authentifizierung wünscht. Werte sind das Codierungsschema und der Bereich, für den eine Authentifizierung erwartet wird.
Beispiel: Proxy-Authenticate: Basic realm=“XTMLWorld“
Retry-After
Das Retry-After-Feld teilt dem Client mit, eine Anfrage zu einem späteren Zeitpunkt erneut zu versuchen. Als Wert wird der Zeitraum in Sekunden angegeben oder ein HTTP-Datum.
Beispiel: Retry-After: 1234
Server
Das Server-Feld gibt zusätzliche Informationen über den Server preis. Zum Beispiel die Serversoftware.
Beispiel: Server: Apache/2.0
Set-Cookie
Das Set-Cookie-Feld gibt dem Client die Anweisung einen Cookie zu speichern. Außerdem kann es Informationen über die Gültigkeitsdauer und den Pfad, für den das Cookie gültig sein soll, enthalten.
Vary
Der Vary-Header-Feld teilt dem Client mit, dass es für seine Anfrage mehrere Quellen gibt. Außerdem enthält es Angaben zur Sprache oder zum Dateityp.
WWW-Authenticate
Das WWW-Authenticate-Feld teilt dem Client mit, dass er sich authentifizieren muss.

Zusammenfassung

Im Kontext des Hypertext-Transfer-Protokolls (HTTP) stellt der HTTP-Header eine Schlüsselkomponente dar, die eine Rolle in der Kommunikation zwischen Server und Webbrowser spielt. Er enthält spezifische Informationen wie den Absender, den Empfänger, die Codierung und Methoden für den Datenaustausch. Nachdem der Client eine Anfrage an den Server geschickt hat, erhält er eine Antwort und die angeforderte Datei wird übertragen.

HTTP-Header-Request-Felder wie „Accept“, „Authorization“, „Cookie“ und „User-Agent“ legen verschiedene Aspekte der Kommunikation fest. Sie spezifizieren zum Beispiel die akzeptierten Dateitypen, Authentifizierungsdaten oder auch den Browser des Clients.

Einige andere Felder wie „Accept-Encoding“ und „Accept-Language“ erklären, welche Codierungsverfahren der Client versteht und welche Sprachen er bevorzugt. Auch gibt es Felder, die spezielle Anforderungen oder Bedingungen für den Datenaustausch stellen, wie „If-Modified-Since“ und „If-None-Match“.

In ähnlicher Weise umfassen HTTP-Header-Response-Felder Angaben wie „Server“, „Set-Cookie“ und „Location“. Diese Felder können Angaben zur Serversoftware, Anweisungen zur Speicherung von Cookies oder die neue Position eines umgezogenen Dokuments beinhalten.

Ein effektives Verständnis der diversen HTTP-Header und ihrer Felder ist entscheidend für eine optimierte Webkommunikation, sowohl von unserer SEO-Agentur als auch für Entwickler im Allgemeinen.

Häufige Fragen und Antworten