HTTP-Header-Felder

HTTP-Header-Felder sind Bestandteile des Hypertext Transfer Protocol (HTTP)-Protokollheaders (RFC 2616) und übermitteln die für die Übertragung von Dateien über HTTP wichtigen Parameter und Argumente, z. B. gewünschte Sprache oder Zeichensatz sowie oft Informationen über den Client.

Die einzelnen Felder im Header werden immer nach der Anfrage-(Request)-Zeile (z. B. GET /index.html HTTP/1.1) bzw. der Antwort-(Response)-Zeile (bei Erfolg HTTP/1.1 200 OK) übermittelt. Die Zeilen des Headers selbst sind Schlüssel-Wert-Paare, getrennt durch Doppelpunkte (z. B. Content-type: text/html). Die Namen sind durch verschiedene Standards fest spezifiziert. Die Zeilenenden werden durch die Zeichenkombination CR LF (carriage return, line feed – auch \r\n) markiert, das Ende des Headers wird durch eine Leerzeile signalisiert, was der Übermittlung von <CR><LF><CR><LF> (oder \r\n\r\n) gleicht.

Die meisten Headerfelder werden durch RFC’s der IETF standardisiert, z. B. der „Kern“ in (RFC 2616 und Erweiterungen in (RFC 4229. Die in diesen Spezifikationen getroffenen Standards müssen in allen HTTP-Implementierungen vorhanden sein. Zusätzlich können Hersteller oder Projekte zusätzliche Erweiterungen in ihre Software einbauen (für die dann allerdings keine Garantie besteht, dass sie von allen Implementierungen korrekt „verstanden“ werden). Je nach Anwendung kann auch der einzelne Administrator oder Entwickler eigene Headerfelder definieren.

Einsehen lassen sich die dauerhaften und provisorischen Headerfelder bei der (IANA.

Standardisierte Felder

Anfrage-Headerfelder

Die Anfrage-Felder kommen im Header der Anfrage eines Browsers an einen Webserver vor. Sie beinhalten z. B. Informationen über die angeforderte Datei und die vom Browser angenommenen Dateitypen.

Name des Felds Beschreibung Beispiel
Accept Welche Dateitypen der Browser verarbeiten kann. Laut RFC 2616, Abschnitt 14 muss der Server den HTTP-Statuscode 406 Not acceptable senden, falls er keinen der „akzeptablen“ Dateitypen bereithält und über Content Negotiation senden kann. Fehlt das Accept-Feld, so bedeutet dies, dass der Client alle Dateitypen akzeptiert. Bei diesem Beispiel wird der Server bei einer Anfrage „foo“ aus einer Auswahl von foo.html und foo.txt die Datei foo.html senden, da sie dem bevorzugten MIME-Typ entspricht (text/html). Accept: text/html, application/xhtml+xml, application/xml; q=0.9,*/*;q=0.8
Accept-Charset Welche Zeichensätze der Browser anzeigen kann und somit empfangen möchte. Die passende Datei wird über Content Negotiation (z. B. bei Apache mod_negotiation) herausgesucht. Accept-Charset: utf-8
Accept-Encoding Welche komprimierten Formate der Browser unterstützt. Über Content Negotiation wird eine passend komprimierte Datei ausgeliefert. Accept-Encoding: gzip,deflate
Accept-Language Welche Sprachen der Browser akzeptiert. Falls der Server passend eingerichtet ist und die Sprachversionen vorhanden sind, wird über Content Negotiation die passende Datei ausgeliefert. Accept-Language: de-DE
Authorization Authentifizierungsdaten für HTTP-Authentifizierungsverfahren Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control Wird genutzt, um Optionen festzulegen, denen durch alle Caching-Mechanismen entlang der Anfrage-/Antwort-Kette Folge geleistet werden muss. Cache-Control: no-cache
Connection Welchen Typ von Verbindung der Browser bevorzugt. Connection: close
Cookie ein HTTP-Cookie, das zuvor vom Server mit Set-Cookie gesetzt wurde Cookie: $Version=1; Skin=new;
Content-Length Länge des Bodys in Bytes Content-Length: 348
Content-MD5 Eine Base64-codierte MD5-Checksume des Bodys Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type MIME-Typ des Bodys (hier genutzt für POST- und PUT-Operationen) Content-Type: application/x-www-form-urlencoded
Date Datum und Zeit zum Sendezeitpunkt der Anfrage Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect Zeigt, welches Verhalten der Client vom Server erwartet. Falls der Server diesen Header nicht versteht oder das Verhalten nicht erfüllen kann, muss er den Code 417 Expectation Failed senden. Der Client sendet ein Expect: 100-continue, wenn er nur den Header, aber nicht den Body einer (sehr großen) Anfrage sendet und daraufhin den HTTP-Statuscode 100 Continue als Bestätigung erwartet, um eine evtl. sehr große Anfrage schicken zu können. Zweck ist hierbei sicherzugehen, dass der Server die (sehr große) Anfrage annehmen wird. Expect: 100-continue
From E-mail-Adresse des Nutzers, der die Anfrage stellte (heute unüblich). RFC 2616 sagt hierzu, dass der From: nicht ohne ausdrückliche Genehmigung des Nutzers gesendet werden darf. From: nobs.nobody@gmx.de
Host Domain-Name des Servers, zwingend vorgeschrieben seit HTTP/1.1 und nötig für namensbasierte Hosts. Bei Fehlen dieses Headers muss der Server nach Definition mit 400 Bad Request antworten. Host: php.nobs-nobody.de
If-Match Aktion nur durchführen, falls der gesendete Code mit dem auf dem Server vorhandenen Code übereinstimmt. Wird z. B. für Aktionen genutzt, die nur dann ausgeführt werden sollen, falls sich etwas verändert hat. If-Match: „737060cd8c284d8af7ad3082f209582d“
If-Modified-Since Erlaubt dem Server, den Statuscode 304 Not Modified zu senden, falls sich seit dem angegebenen Zeitpunkt nichts verändert hat. If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match Erlaubt dem Server bei unverändertem Inhalt (verifiziert durch ETags) den Statuscode 304 Not Modified als Antwort, siehe HTTP ETag If-None-Match: „737060cd8c284d8af7ad3082f209582d“
If-Range Falls der Client einen Teil einer Datei vom Server im Cache liegen hat, die sich auf dem Server nicht verändert hat, nur den fehlenden Rest senden; ansonsten ganze Datei schicken. If-Range: „737060cd8c284d8af7ad3082f209582d“
If-Unmodified-Since Nur dann die Seite senden, falls diese seit dem angegebenen Zeitpunkt nicht geändert wurde. Wurde die Seite geändert, so sendet der Server den Statuscode 412 Precondition Failed, bei unveränderter Seite unterscheidet sich die Antwort nicht von einer normalen Antwort und der Client erhält einen 2xx-Statuscode (Success). If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Forwards Begrenzt die Anzahl der möglichen Weiterleitungen durch Proxys oder Gateways. Das Feld enthält die verbleibende Anzahl an Weiterleitungen, somit muss jeder Proxy diese Zahl aktualisieren (dekrementieren) Max-Forwards: 10
Pragma Das Feld Pragma enthält Optionen, die möglicherweise nur von einigen Implementationen verstanden werden und sich an alle Glieder in der Frage-Antwort-Kette richten. Pragma: no-cache
Proxy-Authorization Im Feld Proxy-Authorization können Autorisierungsdaten für Proxys mit Autorisierungszwang eingebettet werden. Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range Enthält eine Bereichsangabe für den Bereich, den der Client vom Server anfordert (in diesem Beispiel nur die Bytes 500-999) Range: bytes=500-999
Referer Im Feld Referer ist der URI der verweisenden Seite enthalten. Klickt man also auf der Hauptseite der deutschsprachigen Wikipedia einen Link an, so sendet der Browser dem Server der aufgerufenen Seite ein Headerfeld wie im Beispiel. (Das Wort „Referer“ ist, sowohl im RFC als auch in den meisten Implementationen falsch geschrieben; richtig wäre „Referrer“ (von to refer, referred, referred) Referer: http://php.nobs-nobody.de/show/home/
TE Welche Formate der Client annehmen kann, möglich sind hier z. B. gzip oder deflate. „trailers“ gibt hier an, dass der Client das Feld „Trailer“ in den einzelnen Stücken beim Encoding-Modus „Chunked“ akzeptiert und auswertet. (Siehe hierzu Kapitel 3.6, 3.6.1, 14.39, 14.40 in RFC 2616) TE: trailers, deflate
Upgrade Vorschlag an den Server, ein anderes Protokoll zu nutzen Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent Der User-Agent-String des Clients. In ihm stehen Informationen über den Client, sodass z. B. ein serverseitiges Skript an verschiedene Browser angepasste Inhalte ausliefern kann (z. B. bei Downloadseiten, bei denen für Mac OS andere Links angeboten werden sollen als für Microsoft Windows) User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Via Gibt dem Server Informationen über Proxys im Übertragungsweg. Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning Allgemeine Warnungen über den Umgang mit dem Body oder den Body selbst. Warning: 199 Miscellaneous warning

Antwort-Headerfelder

Headerfeld Beschreibung Beispiel
Accept-Ranges Welche Einheiten für Range-Angaben der Server akzeptiert. Accept-Ranges: bytes
Age Wie lange das Objekt im Proxy-Cache gelegen hat. Age: 12
Allow Erlaubte Aktionen für eine bestimmte Ressource. Muss u. a. mit einem 405 Method Not Allowed gesendet werden Allow: GET, HEAD
Cache-Control Teilt allen Caching-Mechanismen entlang der Abrufkette (z. B. Proxys) mit, ob und wie lange das Objekt gespeichert werden darf (in sec) Cache-Control: max-age=3600
Connection bevorzugte Verbindungsarten Connection: close
Content-Encoding Codierung des Inhalts Content-Encoding: gzip
Content-Language Die Sprache, in der die Datei vorliegt (nur sinnvoll bei Content-Negotiation). Wird gesendet, falls der Server mittels Content Negotiation entweder eine Sprache erkannt und ausliefert oder wenn der Server anhand der Endung eine Sprache erkennt. Content-Language: de
Content-Length Länge des Body in Bytes Content-Length: 348
Content-Location Alternativer Name/Speicherplatz für das angeforderte Element. Wird mittels CN beispielsweise „kontakt.html“ angefordert, und der Server schickt aufgrund des Accept-language-Felds die deutsche Version, die eigentlich unter kontakt.de.html liegt, zurück, so wird in Content-Location der Name der Originaldatei geschrieben Content-Location: /kontakt.de.html
Content-MD5 Die Base64-codierte MD5-Checksumme des Body Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Disposition Mit diesem nicht standardisierten und als gefährlich eingestuften Feld kann der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen. Content-Disposition: attachment; filename=fname.ext
Content-Range Welchen Bereich des Gesamtbodys der gesendete Inhalt abdeckt Content-Range: bytes 21010-47021/47022
Content-Security-Policy Sicherheitskonzept, um Cross-Site-Scripting (XSS) and ähnliche Angriffe abzuwehren Content-Security-Policy: default-src https://cdn.incapsula.com; frame-src ’none‘; object-src ’none‘
Content-Type Der MIME-Typ der angeforderten Datei. Er kann nicht mit einer Charset Angabe im HTML header überschrieben werden. Content-Type: text/html; charset=utf-8
Date Zeitpunkt des Absendens Date: Tue, 15 Nov 1994 08:12:31 GMT
ETag Eine bestimmte Version einer Datei, oft als Message Digest realisiert ETag: „737060cd8c284d8af7ad3082f209582d“
Expires Ab wann die Datei als veraltet angesehen werden kann Expires: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified Zeitpunkt der letzten Änderung an der Datei (als RFC 2822) Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Link Wird benutzt, um dem Browser „verwandte“ Dateien oder Ressourcen mitzuteilen, z. B. einen RSS-Feed, einen Favicon, Copyright-Lizenzen etc. Dieses Header-Feld ist äquivalent zum <link />-Feld in (X)HTML. Link: </feed>; rel=“alternate“
Location Oft genutzt, um Clients weiterzuleiten (mit einem 3xx-Code) Location: http://php.nobs-nobody.de/simple/
P3P Dieses Feld wird genutzt, um eine P3P-Datenschutz-Policy wie folgt mitzuteilen:P3P:CP=“your_compact_policy“. P3P setzte sich nicht richtig durch,[5] wird jedoch von einigen Browsern und Webseiten genutzt, um z. B. Cookie-Richtlinien durchzusetzen oder zu überprüfen. P3P: CP=“This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info.“
Pragma Implementierungs-spezifische Optionen, die mehrere Stationen in der Request-Response-Kette beeinflussen können. Pragma: no-cache
Proxy-Authenticate Anweisung, ob und wie der Browser sich beim Proxy zu authentifizieren hat Proxy-Authenticate: Basic
Refresh Refresh wird genutzt, um nach einer bestimmten Zahl von Sekunden weiterzuleiten oder die Seite zu aktualisieren. Dieses Headerfeld ist proprietär und kommt von Netscape, wird aber von den meisten Browsern unterstützt Refresh: 5; url=http://html.nobs-nobody.de/home.html
Retry-After Falls eine Ressource zeitweise nicht verfügbar ist, so teilt der Server dem Client mit diesem Feld mit, wann sich ein neuer Versuch lohnt. Retry-After: 120
Server Serverkennung (so wie User-Agent für den Browser ist, ist Server für die Serversoftware) Server: Apache/2.2.24 (Unix)
Set-Cookie Ein Cookie Set-Cookie: UserID=nobs Max-Age=3600; Version=1
Trailer Das Trailer-Feld enthält die Namen der Headerfelder, die im Trailer der Antwort (bei Chunked-Encoding) enthalten sind. Eine Nachricht in Chunked-Encoding ist aufgeteilt in den Header (Kopf), den Rumpf (Body) und den Trailer, wobei der Rumpf aus Effizienzgründen in Teile (Chunks) aufgeteilt sein kann. Der Trailer kann dann (je nach Wert des TE-Felders der Anfrage) Header-Informationen beinhalten, deren Vorabberechnung der Effizienzsteigerung zuwiderläuft. Trailer: Max-Forwards
Transfer-Encoding Die Methode, die genutzt wird, den Inhalt sicher zum Nutzer zu bringen. Zurzeit sind folgende Methoden definiert: chunked (aufgeteilt), compress (komprimiert), deflate (komprimiert), gzip (komprimiert), identity. Transfer-Encoding: chunked
Vary Zeigt Downstream-Proxys, wie sie anhand der Headerfelder zukünftige Anfragen behandeln sollen, also ob die gecachte Antwort genutzt werden kann oder eine neue Anfrage gestellt werden soll. Vary: *
Via Informiert den Client, über welche Proxys die Antwort gesendet wurde. Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning Eine allgemeine Warnung vor Problemen mit dem Body Warning: 199 Miscellaneous warning
WWW-Authenticate Definiert die Authentikationsmethode, die genutzt werden soll, um eine bestimmte Datei herunterzuladen (Genauer definiert in (RFC 2617) WWW-Authenticate: Basic

Allgemeine, nicht-standardisierte Felder

Anfrage-Felder

Nicht-standardisierte Header tragen oft ein ‚X-‚ am Anfang. Mit (RFC 6648 gilt der Präfix X- als veraltet.

Feldname Beschreibung Beispiel
X-Requested-With Oft genutzt bei Ajax. X-Requested-With: XMLHttpRequest
X-Do-Not-Track Befiehlt einer Website, das Verfolgen (Tracken) des Nutzers zu deaktivieren. Bis jetzt wird dieses Feld von den allermeisten Servern ignoriert. Dies könnte sich jedoch in der Zukunft noch ändern. Siehe auch das Feld ‚DNT‘ X-Do-Not-Track: 1
DNT Befiehlt einer Website, den Nutzer nicht zu tracken. Dieses Feld ist Mozillas Version des X-Do-Not-Track-Felds, wird aber auch von Safari 5 und Internet Explorer 9 unterstützt. Am 7. März 2011 wurde ein Entwurf bei der IETF eingereicht. DNT: 1
X-Forwarded-For ein Quasi-Standard für die Identifizierung der Original-IP-Adresse des Clients, der sich mit einem Webserver über einen HTTP-Proxy oder HTTP-Load-Balancer verbindet X-Forwarded-For: client1, proxy1, proxy2
X-Forwarded-Proto ein Quasi-Standard für die Identifizierung des Original-HTTP-Requests, wenn ein Reverse Proxy (Load Balancer) mit einem Webserver über HTTP kommuniziert X-Forwarded-Proto: https

Antwort-Felder

Feldname Beschreibung Beispiel
X-Frame-Options Clickjacking-Schutz: „deny“ – kein Rendering in einem Frame; „sameorigin“ – Nur dann kein Rendering, falls die Herkunft falsch ist. X-Frame-Options: deny
X-XSS-Protection Cross-Site-Scripting (XSS) Filter X-XSS-Protection: 1; mode=block
X-Content-Type-Options der einzige Wert, „nosniff“, soll den Internet Explorer vor MIME-Sniffing schützen X-Content-Type-Options: nosniff
X-Powered-By spezifiziert die Technologie (ASP.NET, PHP, JBoss, e.g.) über die eine Webanwendung arbeitet (Versionsdetails stehen oft in X-Runtime, X-Version oder X-AspNet-Version) X-Powered-By: PHP/5.2.17

Quelle: Wikipedia

Ein Gedanke zu „HTTP-Header-Felder

  1. website

    You really make it seem so easy with your presentation but I find this topic to be actually something that I think I would never understand.
    It seems too complicated and extremely broad for me. I am looking forward for your next post, I will try to get the hang
    of it!

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.