HTTP Header: Unterschied zwischen den Versionen
(→Ähnliche Artikel) |
|||
| (13 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 4: | Zeile 4: | ||
[[File:HTTP-Header.png|mini|450px|rechts|alt=HTTP Header|'''Abbildung:''' HTTP Header - Autor: Seobility - Lizenz: [[Creative Commons Lizenz BY-SA 4.0|CC BY-SA 4.0]]|link=https://www.seobility.net/de/wiki/images/d/d2/HTTP-Header.png]] | [[File:HTTP-Header.png|mini|450px|rechts|alt=HTTP Header|'''Abbildung:''' HTTP Header - Autor: Seobility - Lizenz: [[Creative Commons Lizenz BY-SA 4.0|CC BY-SA 4.0]]|link=https://www.seobility.net/de/wiki/images/d/d2/HTTP-Header.png]] | ||
| − | Der HTTP Header gehört zum HTTP | + | Der HTTP Header gehört zum [[Hypertext]] Transfer Protocol (HTTP) und überträgt während HTTP Requests oder Responses zusätzliche Informationen. Neben den Daten die vom Webserver der aufgerufenen Website an einen Browser ausgeliefert werden, tauschen Server und Browser über den HTTP Header sogenannte Meta-Informationen über das Dokument aus. |
Ein HTTP Request beinhaltet also einen Header-Bereich, der Informationen wie etwa das Datum der Anfrage, den Referrer oder die bevorzugte Sprache enthält. Auch die HTTP Response enthält ein Header-Feld, in dem der Server seine Informationen an den Browser des Nutzers übermittelt. Dieser Informationsaustausch ist für den Endnutzer üblicherweise unsichtbar. | Ein HTTP Request beinhaltet also einen Header-Bereich, der Informationen wie etwa das Datum der Anfrage, den Referrer oder die bevorzugte Sprache enthält. Auch die HTTP Response enthält ein Header-Feld, in dem der Server seine Informationen an den Browser des Nutzers übermittelt. Dieser Informationsaustausch ist für den Endnutzer üblicherweise unsichtbar. | ||
| Zeile 12: | Zeile 12: | ||
Werte, die für den HTTP Header genutzt werden können, sind in den sogenannten RFC (“Requests for Comments”) festgelegt. Neben den festgelegten Feldern gibt es auch nicht-standardisierte Header, in die benutzerdefinierte Informationen eingetragen werden. Diese Header beginnen üblicherweise mit einem <code>x-</code>. | Werte, die für den HTTP Header genutzt werden können, sind in den sogenannten RFC (“Requests for Comments”) festgelegt. Neben den festgelegten Feldern gibt es auch nicht-standardisierte Header, in die benutzerdefinierte Informationen eingetragen werden. Diese Header beginnen üblicherweise mit einem <code>x-</code>. | ||
| − | == Beispiele für Request Header-Felder | + | == Beispiele für Request Header-Felder == |
| − | Nachfolgend | + | Nachfolgend einige Beispiele für HTTP Request Header-Felder. Eine umfassende Übersicht über alle Request- und Response-Header-Felder findest Du unter https://de.wikipedia.org/wiki/Liste_der_HTTP-Headerfelder. |
| + | |||
| + | === Accept Felder === | ||
| + | |||
| + | Die folgenden Felder geben Auskunft darüber, welche Art von Antwort vom Server akzeptiert wird. | ||
'''Accept''' | '''Accept''' | ||
| Zeile 26: | Zeile 30: | ||
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> | + | <pre>Accept: text/plain; q=0,5, text/html, text/x-dvi; q=0.8, Text/x-c</pre> |
'''Die zur Verfügung stehenden Direktiven sind dabei:''' | '''Die zur Verfügung stehenden Direktiven sind dabei:''' | ||
| Zeile 54: | Zeile 58: | ||
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> | + | <pre>Accept-Charset: iso-8859-5, Unicode-1-1; q=0,8</pre> |
'''Accept-Encoding''' | '''Accept-Encoding''' | ||
| − | + | Das Accept-Encoding Feld legt fest, welcher Kodierungsalgorithmus für die zurückgesendete Ressource verwendet werden kann. | |
Die Syntax sieht dabei so aus: | Die Syntax sieht dabei so aus: | ||
| Zeile 74: | Zeile 78: | ||
'''Accept-Language''' | '''Accept-Language''' | ||
| − | Das Accept-Language-Feld des Headers informiert den Server über die für Menschen lesbare Sprache, die der Server voraussichtlich zurücksendet. Dies ist ein Hinweis und unterliegt nicht unbedingt der vollständigen Kontrolle des Benutzers. Der Server sollte immer darauf achten, eine explizite Benutzerauswahl nicht zu überschreiben | + | Das Accept-Language-Feld des Headers informiert den Server über die für Menschen lesbare Sprache, die der Server voraussichtlich zurücksendet. Dies ist ein Hinweis und unterliegt nicht unbedingt der vollständigen Kontrolle des Benutzers. Der Server sollte immer darauf achten, eine explizite Benutzerauswahl nicht zu überschreiben. |
Die Syntax lautet: | Die Syntax lautet: | ||
| Zeile 86: | Zeile 90: | ||
Erlaubte Werte sind in RFC 1766 angegeben. | Erlaubte Werte sind in RFC 1766 angegeben. | ||
| − | + | === Authorization === | |
Mit dem Authorization Feld werden Anmeldeinformationen zur Authentifizierung eines user-agents an den Server gesendet. Die Syntax lautet: | Mit dem Authorization Feld werden Anmeldeinformationen zur Authentifizierung eines user-agents an den Server gesendet. Die Syntax lautet: | ||
| − | < | + | <pre>Authorization: <type> <credentials></pre> |
| − | + | === Cookie === | |
| − | Der Cookie HTTP-Request-Header enthält gespeicherte HTTP Cookies in Form von Name / Wert Paaren, die zuvor vom Server mit dem Set-Cookie-Header gesendet wurden. Diese Verhalten kann von Browsern geblockt werden, so dass keine Übertragung von Cookies an den Server stattfindet. | + | Der [[Cookie]] HTTP-Request-Header enthält gespeicherte HTTP Cookies in Form von Name / Wert Paaren, die zuvor vom Server mit dem Set-Cookie-Header gesendet wurden. Diese Verhalten kann von Browsern geblockt werden, so dass keine Übertragung von Cookies an den Server stattfindet. |
<pre>Cookie: Name1=Wert1; Name2=Wert2; Name3=Wert3</pre> | <pre>Cookie: Name1=Wert1; Name2=Wert2; Name3=Wert3</pre> | ||
| − | + | === Expect === | |
Der HTTP-Request-Header Expect benennt die Erwartungen des Client, die vom Server erfüllt werden müssen, damit die Anforderung ordnungsgemäß verarbeitet werden kann. | Der HTTP-Request-Header Expect benennt die Erwartungen des Client, die vom Server erfüllt werden müssen, damit die Anforderung ordnungsgemäß verarbeitet werden kann. | ||
| Zeile 106: | Zeile 110: | ||
<pre>Expect : 100-continue</pre> | <pre>Expect : 100-continue</pre> | ||
| − | + | === From === | |
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: | ||
| Zeile 114: | Zeile 118: | ||
Dieses From Feld kann zum Zweck der Protokollierung verwendet werden und erlaubt eine Kontaktaufnahme im Problemfall. | Dieses From Feld kann zum Zweck der Protokollierung verwendet werden und erlaubt eine Kontaktaufnahme im Problemfall. | ||
| − | + | === Host === | |
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: | ||
| Zeile 121: | Zeile 125: | ||
Fehlt die Angabe der Portnummer, impliziert dies den Standard-Port 80. | Fehlt die Angabe der Portnummer, impliziert dies den Standard-Port 80. | ||
| + | |||
| + | === If Felder === | ||
| + | |||
| + | Über die folgenden Felder werden bestimmte Bedingungen für die Auslieferung der angeforderten Dateien übermittelt: | ||
'''If-Match''' | '''If-Match''' | ||
| Zeile 177: | Zeile 185: | ||
Dieses Feld wir analog zum Feld If-Modified-Since verwendet. | Dieses Feld wir analog zum Feld If-Modified-Since verwendet. | ||
| − | + | === Proxy-Authorization === | |
Das Proxy-Authorization-Header-Feld ermöglicht dem Client, sich selbst oder den Benutzer gegenüber einem Proxy zu identifizieren. Syntax: | Das Proxy-Authorization-Header-Feld ermöglicht dem Client, sich selbst oder den Benutzer gegenüber einem Proxy zu identifizieren. Syntax: | ||
| Zeile 183: | Zeile 191: | ||
<pre>Proxy-Authorization : <type> <credentials></pre> | <pre>Proxy-Authorization : <type> <credentials></pre> | ||
| − | + | === Range === | |
Das Range-Header-Feld spezifiziert die Teilbereiche des Inhalts, die angefordert werden. Die Syntax lautet: | Das Range-Header-Feld spezifiziert die Teilbereiche des Inhalts, die angefordert werden. Die Syntax lautet: | ||
| Zeile 191: | Zeile 199: | ||
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. | ||
| − | + | === Referer === | |
Über das Referer-Header-Feld kann der Client die Adresse (URL) der Ressource angeben, von der die URL angefordert wurde. Die allgemeine Syntax lautet: | Über das Referer-Header-Feld kann der Client die Adresse (URL) der Ressource angeben, von der die URL angefordert wurde. Die allgemeine Syntax lautet: | ||
| Zeile 201: | Zeile 209: | ||
<pre>Referer: <nowiki>http://www.seobility.net/http/index.htm</nowiki></pre> | <pre>Referer: <nowiki>http://www.seobility.net/http/index.htm</nowiki></pre> | ||
| − | + | === User-Agent === | |
Dieses Header-Feld sendet Informationen über den Client an den Server. Die Syntax lautet beispielsweise: | Dieses Header-Feld sendet Informationen über den Client an den Server. Die Syntax lautet beispielsweise: | ||
| Zeile 223: | Zeile 231: | ||
} | } | ||
</script></html> | </script></html> | ||
| + | |||
| + | {| class="wikitable" style="text-align:left" | ||
| + | |- | ||
| + | |'''Über den Autor''' | ||
| + | |- | ||
| + | | [[File:Seobility S.jpg|link=|100px|left|alt=Seobility S]] Das Seobility Wiki Team besteht aus SEO-, Online-Marketing- und Web-Experten mit praktischer Erfahrung in den Bereichen Suchmaschinenoptimierung, Online-Marketing und Webentwicklung. Alle unsere Artikel durchlaufen einen mehrstufigen Redaktionsprozess, um Dir die bestmögliche Qualität und wirklich hilfreiche Informationen bieten zu können. <html><a href="https://www.seobility.net/de/wiki/Seobility_Wiki_Team" target="_blank">Mehr Informationen über das Seobility Wiki Team</a></html>. | ||
| + | |} | ||
| + | |||
| + | <html><script type="application/ld+json"> | ||
| + | { | ||
| + | "@context": "https://schema.org", | ||
| + | "@type": "Article", | ||
| + | "author": { | ||
| + | "@type": "Organization", | ||
| + | "name": "Seobility", | ||
| + | "url": "https://www.seobility.net/" | ||
| + | } | ||
| + | } | ||
| + | </script></html> | ||
Aktuelle Version vom 23. Januar 2024, 14:13 Uhr
Inhaltsverzeichnis
Definition
Der HTTP Header gehört zum Hypertext Transfer Protocol (HTTP) und überträgt während HTTP Requests oder Responses zusätzliche Informationen. Neben den Daten die vom Webserver der aufgerufenen Website an einen Browser ausgeliefert werden, tauschen Server und Browser über den HTTP Header sogenannte Meta-Informationen über das Dokument aus.
Ein HTTP Request beinhaltet also einen Header-Bereich, der Informationen wie etwa das Datum der Anfrage, den Referrer oder die bevorzugte Sprache enthält. Auch die HTTP Response enthält ein Header-Feld, in dem der Server seine Informationen an den Browser des Nutzers übermittelt. Dieser Informationsaustausch ist für den Endnutzer üblicherweise unsichtbar.
HTTP Header beinhalten Felder, welche wiederum aus einer Zeile bestehen. Jede Zeile enthält ein durch einen Doppelpunkt getrenntes Name / Wert-Paar (Englisch: Key-Value Pair) und wird durch einen Zeilenumbruch abgeschlossen.
Werte, die für den HTTP Header genutzt werden können, sind in den sogenannten RFC (“Requests for Comments”) festgelegt. Neben den festgelegten Feldern gibt es auch nicht-standardisierte Header, in die benutzerdefinierte Informationen eingetragen werden. Diese Header beginnen üblicherweise mit einem x-.
Beispiele für Request Header-Felder
Nachfolgend einige Beispiele für HTTP Request Header-Felder. Eine umfassende Übersicht über alle Request- und Response-Header-Felder findest Du unter https://de.wikipedia.org/wiki/Liste_der_HTTP-Headerfelder.
Accept Felder
Die folgenden Felder geben Auskunft darüber, welche Art von Antwort vom Server akzeptiert wird.
Accept
Das Feld informiert den Server welche Art von Daten zurückgesendet werden kann.
Über das Feld Accept im HTTP-Request können bestimmte MIME-Typen angegeben werden, die vom Client akzeptiert werden. Die allgemeine Syntax lautet:
Accept: <MIME_type>/<MIME_subtype> ;q=wert
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
Die zur Verfügung stehenden Direktiven sind dabei:
- Der Client unterstützt genau einen MIME-Type wie etwa text/html:
<MIME_type>/<MIME_subtype>
- Ein MIME-Typ ohne spezifischen Untertyp. image/* passt zu image/png, image/svg, image/gif und allen anderen Bildtypen:
<MIME_type>/*
- Ein beliebiger MIME-Typ:
*/*
Jeder verwendete Wert wird in eine Präferenzreihenfolge gebracht, die unter Verwendung des relativen Qualitätswerts ausgedrückt wird, der als Gewicht (Englisch: weight) bezeichnet wird:
;q= (q-Faktor Gewichtung)
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 Feld legt fest, welcher Kodierungsalgorithmus für die zurückgesendete Ressource verwendet werden kann.
Die Syntax sieht dabei so aus:
Accept-Encoding: Kodierungsarten
Beispiele sind:
Accept-Encoding: gzip
Accept-Encoding: *
Accept-Encoding: gzip;q=0.7
Accept-Language
Das Accept-Language-Feld des Headers informiert den Server über die für Menschen lesbare Sprache, die der Server voraussichtlich zurücksendet. Dies ist ein Hinweis und unterliegt nicht unbedingt der vollständigen Kontrolle des Benutzers. Der Server sollte immer darauf achten, eine explizite Benutzerauswahl nicht zu überschreiben.
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 zur Authentifizierung eines user-agents an den Server gesendet. Die Syntax lautet:
Authorization: <type> <credentials>
Cookie
Der Cookie HTTP-Request-Header enthält gespeicherte HTTP Cookies in Form von Name / Wert Paaren, die zuvor vom Server mit dem Set-Cookie-Header gesendet wurden. Diese Verhalten kann von Browsern geblockt werden, so dass keine Übertragung von Cookies an den Server stattfindet.
Cookie: Name1=Wert1; Name2=Wert2; Name3=Wert3
Expect
Der HTTP-Request-Header 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]
Dieses From Feld kann zum Zweck der Protokollierung verwendet werden und erlaubt eine Kontaktaufnahme im Problemfall.
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 Portnummer, impliziert dies den Standard-Port 80.
If Felder
Über die folgenden Felder werden bestimmte Bedingungen für die Auslieferung der angeforderten Dateien übermittelt:
If-Match
Dieses Header-Feld 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-Header-Feld 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.
Proxy-Authorization
Das Proxy-Authorization-Header-Feld ermöglicht dem Client, sich selbst oder den Benutzer gegenüber einem Proxy zu identifizieren. Syntax:
Proxy-Authorization : <type> <credentials>
Range
Das Range-Header-Feld 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-Header-Feld 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
User-Agent
Dieses Header-Feld sendet Informationen über den Client an den Server. Die Syntax lautet beispielsweise:
User-Agent: <product> / <product-version> <comment>
Ähnliche Artikel
| Über den Autor |
 |