HTTP Header: Unterschied zwischen den Versionen
Zeile 23: | Zeile 23: | ||
Über das Feld Accept im HTTP-Request können bestimmte Medientypen angegeben werden, die vom Client akzeptiert werden. Die allgemeine Syntax lautet: | Über das Feld Accept im HTTP-Request können bestimmte Medientypen angegeben werden, die vom Client akzeptiert werden. Die allgemeine Syntax lautet: | ||
− | < | + | <pre>Accept: Typ / Subtyp [q = qwert]</pre> |
Mehrere Medientypen können durch Kommata getrennt aufgeführt werden. Der optionale Wert q steht für die Qualitätsstufe auf einer Skala von 0 bis 1. Beispiel: | Mehrere Medientypen können durch Kommata getrennt aufgeführt werden. Der optionale Wert q steht für die Qualitätsstufe auf einer Skala von 0 bis 1. Beispiel: | ||
− | < | + | <pre>Accept: text / plain; q = 0,5, text / html, text / x-dvi; q = 0.8, Text / x-c</pre> |
Zeile 34: | Zeile 34: | ||
Über das Accept-Charset-Feld wird angegeben werden, welche [[Zeichensatzkodierung|Zeichensätze]] der Client für die Antwort akzeptiert. | Über das Accept-Charset-Feld wird angegeben werden, welche [[Zeichensatzkodierung|Zeichensätze]] der Client für die Antwort akzeptiert. | ||
− | < | + | <pre>Accept-Charset: character-set</pre> |
Werden mehrere Zeichensätze angegeben, müssen sie durch Kommata getrennt eingetragen werden. Beispiel: | Werden mehrere Zeichensätze angegeben, müssen sie durch Kommata getrennt eingetragen werden. Beispiel: | ||
− | < | + | <pre>Accept-Charset: iso-8859-5, Unicode-1-1; q = 0,8</pre> |
Zeile 45: | Zeile 45: | ||
Das Accept-Encoding-Headerfeld beschränkt die Inhaltscodierungen, die in der Antwort akzeptabel sind. Syntax: | Das Accept-Encoding-Headerfeld beschränkt die Inhaltscodierungen, die in der Antwort akzeptabel sind. Syntax: | ||
− | < | + | <pre>Accept-Encoding: Kodierungstypen</pre> |
Beispiele sind: | Beispiele sind: | ||
− | < | + | <pre>Accept-Encoding: gzip</pre> |
− | < | + | <pre>Accept-Encoding: *</pre> |
− | < | + | <pre>Accept-Encoding: gzip; q = 0.7</pre> |
Zeile 60: | Zeile 60: | ||
Das Accept-Language-Headerfeld beschränkt den Satz natürlicher [[Sprache einer HTML Seite|Sprachen]], die als Antwort auf die Anforderung bevorzugt werden. Die Syntax lautet: | Das Accept-Language-Headerfeld beschränkt den Satz natürlicher [[Sprache einer HTML Seite|Sprachen]], die als Antwort auf die Anforderung bevorzugt werden. Die Syntax lautet: | ||
− | < | + | <pre>Accept-Language: Sprache (+ eventuell q = qwert)</pre> |
Mehrere Sprachen können durch Kommata getrennt aufgeführt werden. Beispiel: | Mehrere Sprachen können durch Kommata getrennt aufgeführt werden. Beispiel: | ||
− | < | + | <pre>Accept-Language: de-DE; q = 0.9</pre> |
Erlaubte Werte sind in RFC 1766 angegeben. | Erlaubte Werte sind in RFC 1766 angegeben. | ||
Zeile 80: | Zeile 80: | ||
Das Cookie-Header-Feld enthält ein Name / Wert-Paar mit den Informationen, die für die angefragte URL gespeichert wurden. Dabei können mehrere Cookie-Informationen angegeben werden: | Das Cookie-Header-Feld enthält ein Name / Wert-Paar mit den Informationen, die für die angefragte URL gespeichert wurden. Dabei können mehrere Cookie-Informationen angegeben werden: | ||
− | < | + | <pre>Cookie: Name1 = Wert1; Name2 = Wert2; Name3 = Wert3</pre> |
Zeile 89: | Zeile 89: | ||
Die allgemeine Syntax lautet: | Die allgemeine Syntax lautet: | ||
− | < | + | <pre>Expect : 100-continue</pre> |
Zeile 96: | Zeile 96: | ||
Das From-Feld enthält eine E-Mail-Adresse des Benutzers, der den anfragenden Client steuert. Beispiel: | Das From-Feld enthält eine E-Mail-Adresse des Benutzers, der den anfragenden Client steuert. Beispiel: | ||
− | + | <pre>From: [email protected]</pre> | |
Das From-Feld kann für Protokollierungszwecke und zur Identifizierung verwendet werden. | Das From-Feld kann für Protokollierungszwecke und zur Identifizierung verwendet werden. | ||
Zeile 105: | Zeile 105: | ||
Das Host-Feld wird genutzt, um den Internet-Host und die Port-Nummer für die angeforderte Ressource anzugeben. Die Syntax lautet: | Das Host-Feld wird genutzt, um den Internet-Host und die Port-Nummer für die angeforderte Ressource anzugeben. Die Syntax lautet: | ||
− | < | + | <pre>Host: host:port</pre> |
Fehlt die Angabe der Port-Nummer, impliziert dies den Standard-Port 80. | Fehlt die Angabe der Port-Nummer, impliziert dies den Standard-Port 80. | ||
Zeile 114: | Zeile 114: | ||
Dieses Headerfeld fordert den Server auf, die angeforderte Datei nur dann zu senden, wenn sie den angegebenen Entity-Tags entspricht. Die Syntax lautet: | Dieses Headerfeld fordert den Server auf, die angeforderte Datei nur dann zu senden, wenn sie den angegebenen Entity-Tags entspricht. Die Syntax lautet: | ||
− | < | + | <pre>If-Match: Entity-Tag</pre> |
Beispiel: | Beispiel: | ||
− | < | + | <pre>If-Match: "*"</pre> |
Ein Stern (*) bedeutet, dass jede Datei gesendet werden kann. | Ein Stern (*) bedeutet, dass jede Datei gesendet werden kann. | ||
Zeile 127: | Zeile 127: | ||
Ist If-Modified-Since angegeben, wird eine angeforderte Ressource vom Server nur ausgeliefert, wenn Sie seit dem angegeben Datum verändert wurde. Sonst erfolgt keine Auslieferung und die Seite wird aus dem Cache des Browsers geladen. Syntax: | Ist If-Modified-Since angegeben, wird eine angeforderte Ressource vom Server nur ausgeliefert, wenn Sie seit dem angegeben Datum verändert wurde. Sonst erfolgt keine Auslieferung und die Seite wird aus dem Cache des Browsers geladen. Syntax: | ||
− | < | + | <pre>If-Modified-Since: HTTP-Datum</pre> |
Ein Beispiel ist: | Ein Beispiel ist: | ||
− | < | + | <pre>If-Modified-Since: So, 29. Okt. 2017 19:43:31 GMT</pre> |
Zeile 138: | Zeile 138: | ||
Dieser Header fordert den Server auf, die angeforderte Datei nur dann zu senden, wenn sie keinem der angegebenen Entity-Tags entspricht. Die Syntax lautet: | Dieser Header fordert den Server auf, die angeforderte Datei nur dann zu senden, wenn sie keinem der angegebenen Entity-Tags entspricht. Die Syntax lautet: | ||
− | < | + | <pre>If-None-Match: Entitäts-Tag</pre> |
Beispiele sind: | Beispiele sind: | ||
− | < | + | <pre>If-None-Match: "xyzzy"</pre> |
− | < | + | <pre>If-None-Match: *</pre> |
Zeile 151: | Zeile 151: | ||
Das If-Range-Headerfeld wird verwendet, um nur den Teil des Contents anzufordern, der fehlt, wenn der Inhalt nicht geändert wurde, und den gesamten Content, falls eine Änderung stattgefunden hat. Die Syntax lautet: | Das If-Range-Headerfeld wird verwendet, um nur den Teil des Contents anzufordern, der fehlt, wenn der Inhalt nicht geändert wurde, und den gesamten Content, falls eine Änderung stattgefunden hat. Die Syntax lautet: | ||
− | < | + | <pre>If-Range: Entitäts-Tag / HTTP-Datum</pre> |
Es kann entweder ein Entitäts-Tag oder ein Datum verwendet werden: | Es kann entweder ein Entitäts-Tag oder ein Datum verwendet werden: | ||
− | < | + | <pre>If-Range: So, 29. Okt. 2017 19:43:31 GMT</pre> |
Wenn der Content nicht geändert wurde, gibt der Server den Bytebereich zurück, der vom Range-Header angegeben wurde. Andernfalls wird das gesamte neue Dokument zurückgegeben. | Wenn der Content nicht geändert wurde, gibt der Server den Bytebereich zurück, der vom Range-Header angegeben wurde. Andernfalls wird das gesamte neue Dokument zurückgegeben. | ||
Zeile 164: | Zeile 164: | ||
Die allgemeine Syntax lautet: | Die allgemeine Syntax lautet: | ||
− | < | + | <pre>If-Unmodified-Since: HTTP-Datum</pre> |
Dieses Feld wir analog zum Feld If-Modified-Since verwendet. | Dieses Feld wir analog zum Feld If-Modified-Since verwendet. | ||
Zeile 173: | Zeile 173: | ||
Max-Forwards teilt Proxy-Servern mit, wie oft eine Nachricht maximal weitergeleitet werden darf. Die Syntax lautet: | Max-Forwards teilt Proxy-Servern mit, wie oft eine Nachricht maximal weitergeleitet werden darf. Die Syntax lautet: | ||
− | < | + | <pre>Max-Forwards: n</pre> |
Der Max-Forwards-Wert "n" ist eine Dezimalzahl. Max-Forwards ist nützlich für das Debugging mit der TRACE-Methode, wobei Endlosschleifen vermieden werden. Das Max-Forwards-Headerfeld kann für alle anderen in der HTTP-Spezifikation definierten Methoden ignoriert werden. | Der Max-Forwards-Wert "n" ist eine Dezimalzahl. Max-Forwards ist nützlich für das Debugging mit der TRACE-Methode, wobei Endlosschleifen vermieden werden. Das Max-Forwards-Headerfeld kann für alle anderen in der HTTP-Spezifikation definierten Methoden ignoriert werden. | ||
Zeile 182: | Zeile 182: | ||
Das Proxy-Authorization-Headerfeld ermöglicht dem Client, sich selbst oder den Benutzer gegenüber einem Proxy zu identifizieren. Syntax: | Das Proxy-Authorization-Headerfeld ermöglicht dem Client, sich selbst oder den Benutzer gegenüber einem Proxy zu identifizieren. Syntax: | ||
− | < | + | <pre>Proxy-Authorization : Anmeldeinformationen</pre> |
Zeile 189: | Zeile 189: | ||
Das Range oder Bereichsanforderungs-Headerfeld spezifiziert die Teilbereiche des Inhalts, die angefordert werden. Die Syntax lautet: | Das Range oder Bereichsanforderungs-Headerfeld spezifiziert die Teilbereiche des Inhalts, die angefordert werden. Die Syntax lautet: | ||
− | < | + | <pre>Range: bytes-unit=first-byte-pos "-" [last-byte-pos]</pre> |
Die Werte "first-byte-pos" und "last-byte-pos" geben das erste und letzte Byte des eingeschlossen Content an, müssen aber nicht beide angegeben werden. Mehrere Content Bereiche können durch Kommata getrennt aufgeführt werden. | Die Werte "first-byte-pos" und "last-byte-pos" geben das erste und letzte Byte des eingeschlossen Content an, müssen aber nicht beide angegeben werden. Mehrere Content Bereiche können durch Kommata getrennt aufgeführt werden. | ||
Zeile 198: | Zeile 198: | ||
Über das Referer-Headerfeld kann der Client die Adresse (URL) der Ressource angeben, von der die URL angefordert wurde. Die allgemeine Syntax lautet: | Über das Referer-Headerfeld kann der Client die Adresse (URL) der Ressource angeben, von der die URL angefordert wurde. Die allgemeine Syntax lautet: | ||
− | < | + | <pre>Referer: URL</pre> |
Beispiel: | Beispiel: | ||
− | < | + | <pre>Referer: <nowiki>http://www.seobility.net/http/index.htm</nowiki></pre> |
Zeile 209: | Zeile 209: | ||
Das TE-Headerfeld gibt an, welche Extension-Transfer-Codierung es in der Antwort akzeptiert. Die Syntax lautet: | Das TE-Headerfeld gibt an, welche Extension-Transfer-Codierung es in der Antwort akzeptiert. Die Syntax lautet: | ||
− | < | + | <pre>TE: t-Kodierungen</pre> |
Zeile 216: | Zeile 216: | ||
Dieses Headerfeld sendet Informationen über den Client an den Server. Die Syntax lautet beispielsweise: | Dieses Headerfeld sendet Informationen über den Client an den Server. Die Syntax lautet beispielsweise: | ||
− | < | + | <pre>User-Agent: Mozilla</pre> |
[[Kategorie:Suchmaschinenoptimierung]] | [[Kategorie:Suchmaschinenoptimierung]] | ||
[[Kategorie:Web Entwicklung]] | [[Kategorie:Web Entwicklung]] |
Version vom 24. Oktober 2018, 10:25 Uhr
Definition
Der HTTP Header ist ein Teil der Datenübertragung im Internet. HTTP ist dabei die Abkürzung für Hypertext Transfer Protocol. Bevor die Daten der angeforderten Website vom Webserver an einen Browser ausgeliefert werden, tauschen Server und Browser über den HTTP Header die sogenannten Meta-Informationen über das Dokument oder die Webseite aus.
Mit dem HTTP-Request übermittelt der Browser in der sogenannten request message im Headerbereich Informationen etwa über das Datum der Anfrage, die bevorzugte Sprache oder den Referrer. Diese Informationen werden vom Webserver mit dem HTTP-Response-Header in der response message beantwortet.
Abbildung: HTTP-Request und -Response, Autor: seobility
Der HTTP-Request oder -Response-Header beinhaltet sogenannte Felder, welche wiederum aus jeweils einer Zeile bestehen. Jede Zeile enthält ein durch einen Doppelpunkt getrenntes Name / Wert-Paar und wird durch eine CRLF Zeichenfolge abgeschlossen (CR = Wagenrücklauf und LF = Zeilenvorschub).
Werte, die für den HTTP-Header genutzt werden können, sind in den sogenannten RFC (“Requests for Comments”) festgelegt. Hierbei handelt es sich um formelle Dokumente der Internet Engineering Task Force (IETF), welche unter anderem Standards, die im Internet angewandt werden, beinhalten.
Beispiele für Request Headerfelder
Nachfolgend haben wir eine Auswahl an möglichen Request Headerfeldern für Sie zusammengestellt. Eine umfassende Übersicht über alle Request- und Response-Headerfelder finden Sie unter https://de.wikipedia.org/wiki/Liste_der_HTTP-Headerfelder.
Accept
Über das Feld Accept im HTTP-Request können bestimmte Medientypen angegeben werden, die vom Client akzeptiert werden. Die allgemeine Syntax lautet:
Accept: Typ / Subtyp [q = qwert]
Mehrere Medientypen können durch Kommata getrennt aufgeführt werden. Der optionale Wert q steht für die Qualitätsstufe auf einer Skala von 0 bis 1. Beispiel:
Accept: text / plain; q = 0,5, text / html, text / x-dvi; q = 0.8, Text / x-c
Accept-Charset
Über das Accept-Charset-Feld wird angegeben werden, welche Zeichensätze der Client für die Antwort akzeptiert.
Accept-Charset: character-set
Werden mehrere Zeichensätze angegeben, müssen sie durch Kommata getrennt eingetragen werden. Beispiel:
Accept-Charset: iso-8859-5, Unicode-1-1; q = 0,8
Accept-Encoding
Das Accept-Encoding-Headerfeld beschränkt die Inhaltscodierungen, die in der Antwort akzeptabel sind. Syntax:
Accept-Encoding: Kodierungstypen
Beispiele sind:
Accept-Encoding: gzip
Accept-Encoding: *
Accept-Encoding: gzip; q = 0.7
Accept-Language
Das Accept-Language-Headerfeld beschränkt den Satz natürlicher Sprachen, die als Antwort auf die Anforderung bevorzugt werden. Die Syntax lautet:
Accept-Language: Sprache (+ eventuell q = qwert)
Mehrere Sprachen können durch Kommata getrennt aufgeführt werden. Beispiel:
Accept-Language: de-DE; q = 0.9
Erlaubte Werte sind in RFC 1766 angegeben.
Authorization
Mit dem Authorization-Feld werden Anmeldeinformationen an den Server gesendet. Die Syntax lautet:
Authorization: Anmeldeinformationen
Cookie
Das Cookie-Header-Feld enthält ein Name / Wert-Paar mit den Informationen, die für die angefragte URL gespeichert wurden. Dabei können mehrere Cookie-Informationen angegeben werden:
Cookie: Name1 = Wert1; Name2 = Wert2; Name3 = Wert3
Expect
Der HTTP-Anforderungsheader Expect benennt die Erwartungen des Client, die vom Server erfüllt werden müssen, damit die Anforderung ordnungsgemäß verarbeitet werden kann.
Die allgemeine Syntax lautet:
Expect : 100-continue
From
Das From-Feld enthält eine E-Mail-Adresse des Benutzers, der den anfragenden Client steuert. Beispiel:
From: [email protected]
Das From-Feld kann für Protokollierungszwecke und zur Identifizierung verwendet werden.
Host
Das Host-Feld wird genutzt, um den Internet-Host und die Port-Nummer für die angeforderte Ressource anzugeben. Die Syntax lautet:
Host: host:port
Fehlt die Angabe der Port-Nummer, impliziert dies den Standard-Port 80.
If-Match
Dieses Headerfeld fordert den Server auf, die angeforderte Datei nur dann zu senden, wenn sie den angegebenen Entity-Tags entspricht. Die Syntax lautet:
If-Match: Entity-Tag
Beispiel:
If-Match: "*"
Ein Stern (*) bedeutet, dass jede Datei gesendet werden kann.
If-Modified-Since
Ist If-Modified-Since angegeben, wird eine angeforderte Ressource vom Server nur ausgeliefert, wenn Sie seit dem angegeben Datum verändert wurde. Sonst erfolgt keine Auslieferung und die Seite wird aus dem Cache des Browsers geladen. Syntax:
If-Modified-Since: HTTP-Datum
Ein Beispiel ist:
If-Modified-Since: So, 29. Okt. 2017 19:43:31 GMT
If-None-Match
Dieser Header fordert den Server auf, die angeforderte Datei nur dann zu senden, wenn sie keinem der angegebenen Entity-Tags entspricht. Die Syntax lautet:
If-None-Match: Entitäts-Tag
Beispiele sind:
If-None-Match: "xyzzy"
If-None-Match: *
If-Range
Das If-Range-Headerfeld wird verwendet, um nur den Teil des Contents anzufordern, der fehlt, wenn der Inhalt nicht geändert wurde, und den gesamten Content, falls eine Änderung stattgefunden hat. Die Syntax lautet:
If-Range: Entitäts-Tag / HTTP-Datum
Es kann entweder ein Entitäts-Tag oder ein Datum verwendet werden:
If-Range: So, 29. Okt. 2017 19:43:31 GMT
Wenn der Content nicht geändert wurde, gibt der Server den Bytebereich zurück, der vom Range-Header angegeben wurde. Andernfalls wird das gesamte neue Dokument zurückgegeben.
If-Unmodified-Since
Die allgemeine Syntax lautet:
If-Unmodified-Since: HTTP-Datum
Dieses Feld wir analog zum Feld If-Modified-Since verwendet.
Max-Forwards
Max-Forwards teilt Proxy-Servern mit, wie oft eine Nachricht maximal weitergeleitet werden darf. Die Syntax lautet:
Max-Forwards: n
Der Max-Forwards-Wert "n" ist eine Dezimalzahl. Max-Forwards ist nützlich für das Debugging mit der TRACE-Methode, wobei Endlosschleifen vermieden werden. Das Max-Forwards-Headerfeld kann für alle anderen in der HTTP-Spezifikation definierten Methoden ignoriert werden.
Proxy-Authorization
Das Proxy-Authorization-Headerfeld ermöglicht dem Client, sich selbst oder den Benutzer gegenüber einem Proxy zu identifizieren. Syntax:
Proxy-Authorization : Anmeldeinformationen
Range
Das Range oder Bereichsanforderungs-Headerfeld spezifiziert die Teilbereiche des Inhalts, die angefordert werden. Die Syntax lautet:
Range: bytes-unit=first-byte-pos "-" [last-byte-pos]
Die Werte "first-byte-pos" und "last-byte-pos" geben das erste und letzte Byte des eingeschlossen Content an, müssen aber nicht beide angegeben werden. Mehrere Content Bereiche können durch Kommata getrennt aufgeführt werden.
Referer
Über das Referer-Headerfeld kann der Client die Adresse (URL) der Ressource angeben, von der die URL angefordert wurde. Die allgemeine Syntax lautet:
Referer: URL
Beispiel:
Referer: http://www.seobility.net/http/index.htm
TE
Das TE-Headerfeld gibt an, welche Extension-Transfer-Codierung es in der Antwort akzeptiert. Die Syntax lautet:
TE: t-Kodierungen
User-Agent
Dieses Headerfeld sendet Informationen über den Client an den Server. Die Syntax lautet beispielsweise:
User-Agent: Mozilla