HTTP-Header-Felder (oft ungenau HTTP-Header) sind Bestandteile des Hypertext Transfer Protocol (HTTP)-Protokollheaders 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. Oft wird „HTTP-Header“ synonym genutzt, besitzt allerdings die Mehrdeutigkeit zwischen einem einzelnen Feld des Headerblocks und dem ganzen Headerblock. Hier wird für die Gesamtheit der Headerfelder der Begriff „Header“ und für eine einzelne Zeile im Header der Begriff „Headerfeld“ entsprechend RFC 2616 genutzt.
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) markiert, das Ende des Headers wird durch eine Leerzeile signalisiert, was der Übermittlung von <CR><LF><CR><LF> gleicht.
Die meisten Headerfelder werden durch RFCs 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 Erweiterungen in ihre Software einbauen (für die dann allerdings keine Garantie besteht, dass sie von allen Implementierungen korrekt verstanden werden). Je nach Produkt kann auch der einzelne Anwender oder Administrator eigene Headerfelder definieren.Dokumentation der Direktive header. httpd.apache.org
Da im HTTP-Antwort-Header unter Umständen sicherheitskritische Informationen, wie beispielsweise der verwendete Webserver inklusive Version, ersichtlich sind (z. B. Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)), wird empfohlen, diese zu verbergen.
Einsehen lassen sich die dauerhaften und provisorischen Headerfelder bei der Internet Assigned Numbers Authority (IANA).
Anfrage-Headerfelder Die Anfrage-Felder kommen im Header der Anfrage eines HTTP-Clients (z. B. Browsers) an einen Webserver vor. Sie enthalten z. B. Informationen über die angeforderte Ressource und die vom Client angenommenen MIME-Typen.
Für exakte Nachforschungen sei die Lektüre von RFC 2616, Kapitel 14 empfohlen (Kapitelnummer in der zweiten Spalte der Tabelle).
Name des Felds Kapitel in RFC 2616 Beschreibung Beispiel Accept 14.1 Welche Inhaltstypen der Client verarbeiten kann. Ist es dem Server nicht möglich, einen Inhaltstyp bereitzustellen, der vom Client akzeptiert wird, kann er entweder den HTTP-Statuscode 406 Not acceptable senden oder einen beliebigen Inhaltstyp zum Kodieren der angeforderten Informationen verwenden. Fehlt das Accept-Feld, so bedeutet dies, dass der Client alle Inhaltstypen akzeptiert. Kann der Server in diesem Beispiel den Inhalt der angeforderten Ressource sowohl als HTML als auch als Bild im GIF-Format an den Client senden, führt der Accept-Header der Anfrage dazu, dass als Inhaltstyp der Antwort HTML gewählt wird. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset 14.2 Welche Zeichensätze der Client 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 14.3 Welche komprimierten Formate der Client unterstützt. Über Content Negotiation wird eine passend komprimierte Datei ausgeliefert. Accept-Encoding: gzip,deflate Accept-Language 14.4 Welche Sprachen der Client akzeptiert. Falls der Server passend eingerichtet ist und die Sprachversionen vorhanden sind, wird über Content Negotiation die passende Datei ausgeliefert. Accept-Language: en-US Authorization 14.8 Authentifizierungsdaten für HTTP-Authentifizierungsverfahren Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Cache-Control 14.9 Legt Optionen fest, denen durch alle Caching-Mechanismen entlang der Anfrage-/Antwort-Kette Folge geleistet werden muss. Cache-Control: no-cache Connection 14.10 Steuert, was mit der Verbindung passiert, wenn die Anfrage abgeschlossen ist. Connection: close Cookie HTTP-Cookie, das zuvor vom Server mit Set-Cookie gesetzt wurde Cookie: $Version=1; Skin=new; Content-Length 14.13 Länge des Bodys in Bytes Content-Length: 348 Content-MD5 14.15 Eine Base64-codierte MD5-Checksumme des Bodys Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== Content-Type 14.17 MIME-Typ des Bodys (hier genutzt für POST- und PUT-Operationen) Content-Type: application/x-www-form-urlencoded Date 14.18 Datum und Zeit zum Sendezeitpunkt der Anfrage Date: Tue, 15 Nov 1994 08:12:31 GMT Expect 14.20 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 Forwarded RFC 7239 Dient bei weiterleitenden Reverse Proxies (z. B. Lastverteiler) der Identifizierung des ursprünglich anfragenden Clients, des ursprünglich genutzten Protokolls sowie des ursprünglich angefragten Hosts und Ports, da ein Reverse Proxy diese Informationen funktionsbedingt verändert. Forwarded: by="10.0.0.1"; for="192.168.0.1:4711"; proto=http; host="www.example.com:8080" From 14.22 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: [email protected] Host 14.23 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: en.wikipedia.org If-Match 14.24 Aktion nur durchführen, falls der gesendete Code mit dem auf dem Server vorhandenen Code übereinstimmt. If-Match: "737060cd8c284d8af7ad3082f209582d" If-Modified-Since 14.25 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 14.26 Erlaubt dem Server bei unverändertem Inhalt (verifiziert durch HTTP ETags) den Statuscode 304 Not Modified als Antwort. If-None-Match: "737060cd8c284d8af7ad3082f209582d" If-Range 14.27 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 14.28 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 14.31 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 dekrementieren. Max-Forwards: 10 Pragma 14.32 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 14.34 Autorisierungsdaten für Proxys mit Autorisierungszwang Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Range 14.35 Bereich, den der Client vom Server anfordert (in diesem Beispiel nur die Bytes 500-999) Range: bytes=500-999 Referer[sic] 14.36 URI der verweisenden Seite (insb. bei Webbrowsern). Klickt man bspw. auf der Hauptseite der deutschsprachigen Wikipedia einen Link an, so sendet der Browser dem Server der aufgerufenen Seite das Headerfeld im Beispiel. Referer: https://de.wikipedia.org/wiki/Wikipedia:Hauptseite TE 14.39 Welche Kompressionsformate der Client annehmen kann, möglich sind 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 Transfer-Encoding 14.41 Die Transformationen, die angewendet wurden, um den Inhalt zum Server zu transportieren. Zurzeit sind folgende Methoden definiert: chunked (aufgeteilt), compress (komprimiert), deflate (komprimiert), gzip (komprimiert), identity. Transfer-Encoding: chunked Upgrade 14.42 Vorschlag an den Server, ein anderes Protokoll zu nutzen Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 User-Agent 14.43 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 Windows) User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Via 14.45 Gibt dem Server Informationen über Proxys im Übertragungsweg. Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) Warning 14.46 Allgemeine Warnungen über den Umgang mit dem Body oder den Body selbst. Warning: 199 Miscellaneous warning
Antwort-Headerfelder Headerfeld Kapitel in RFC 2616 Beschreibung Beispiel Accept-Ranges 14.5 Akzeptierte Einheiten für die Range-Angabe Accept-Ranges: bytes Age 14.6 Wie lange das Objekt im Proxy-Cache gelegen hat (in Sekunden). Age: 12 Allow 14.7 Erlaubte Aktionen für eine bestimmte Ressource. Muss u. a. bei einem Statuscode 405 Method Not Allowed mitgesendet werden. Allow: GET, HEAD Cache-Control 14.9 Teilt allen Caching-Mechanismen entlang der Abrufkette (z. B. Proxys) mit, ob und wie lange das Objekt gespeichert werden darf (in Sekunden). Cache-Control: max-age=3600 Cache-Control: no-cache Connection 14.10 Bevorzugte Verbindungsarten Connection: close Content-Encoding 14.11 Codierung des Inhalts Content-Encoding: gzip Content-Language 14.12 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 14.13 Länge des Bodys in Bytes Content-Length: 348 Content-Location 14.14 Alternativer Name/Speicherplatz für das angeforderte Element. Wird mittels CN beispielsweise „foo.html“ angefordert, und der Server schickt aufgrund des Accept-language-Felds die deutsche Version, die eigentlich unter foo.html.de liegt, zurück, so steht hier der Name der Originaldatei. Content-Location: /foo.html.de Content-MD5 14.15 Die Base64-codierte MD5-Checksumme des Bodys Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== Content-Disposition 19.5.11) Zusätzliche Informationen zur Verarbeitung des Payloads. So kann beispielsweise eine Datei als Download markiert werden, sodass Browser nicht versuchen, sie selbst anzuzeigen, sondern einen Download-Dialog öffnen. Content-Disposition: attachment; filename=fname.ext