HTTP-Headerfelder sind eine Liste von durch Zeilenvorschub getrennten HTTP-Daten, die von Client-Programm und Server bei jeder HTTP-Anfrage gesendet und empfangen werden. Diese Header sind in der Regel für den Endbenutzer unsichtbar und nur für die Backend-Programme und Personen sichtbar, die das Internetsystem warten. Sie definieren, wie Informationen, die über die Verbindung gesendet/empfangen werden, kodiert werden (wie in Accept-Encoding), die Sitzungsverifizierung und -identifizierung des Clients (wie in Browser-Cookies, IP-Adresse, User-Agent) oder deren Anonymität (VPN- oder Proxy-Maskierung, User-Agent-Spoofing), wie der Server Daten behandeln soll (wie in Do-Not-Track), das Alter des heruntergeladenen Dokuments, unter anderem.
Allgemeines Format
Die Headerfelder werden nach der Anfragezeile (im Falle einer HTTP-Anfragenachricht) oder der Antwortzeile (im Falle einer HTTP-Antwortnachricht) übertragen, die die erste Zeile einer Nachricht ist. Headerfelder sind durch Doppelpunkte getrennte Schlüssel-Wert-Paare im Klartext-Stringformat, die durch eine Wagenrücklauf- (CR) und Zeilenvorschub- (LF) Zeichenfolge abgeschlossen werden. Das Ende des Header-Abschnitts wird durch eine leere Feldzeile angezeigt, was zur Übertragung von zwei aufeinanderfolgenden CR-LF-Paaren führt. In der Vergangenheit konnten lange Zeilen in mehrere Zeilen umgebrochen werden; Fortsetzungszeilen werden durch das Vorhandensein eines Leerzeichens (SP) oder horizontalen Tabulators (HT) als erstes Zeichen in der nächsten Zeile gekennzeichnet. Diese Faltung ist jetzt veraltet.
Feldnamen
Ein Kernsatz von Feldern wird von der Internet Engineering Task Force (IETF) in den RFCs 7230, 7231, 7232, 7233, 7234 und 7235 Standardisiert. Das permanente Register der Headerfelder und das Repository der vorläufigen Registrierungen werden von der IANA verwaltet. Zusätzliche Feldnamen und zulässige Werte können von jeder Anwendung definiert werden.
Header-Feldnamen sind nicht case-sensitiv. Dies steht im Gegensatz zu HTTP-Methodennamen (GET, POST usw.), die case-sensitiv sind.
HTTP/2 schränkt bestimmte Headerfelder ein (siehe unten).
Nicht-Standard-Headerfelder wurden herkömmlicherweise durch das Voranstellen des Feldnamens mit X- gekennzeichnet, aber diese Konvention wurde im Juni 2012 aufgrund der Unannehmlichkeiten, die sie verursachte, als Nicht-Standard-Felder Standard wurden, verworfen. Eine frühere Einschränkung der Verwendung von Downgraded wurde im März 2013 aufgehoben.
Feldwerte
Einige Felder können Kommentare enthalten (d. h. in den Feldern User-Agent, Server, Via), die von der Software ignoriert werden können.
Viele Feldwerte können ein Qualitäts- (q) Schlüssel-Wert-Paar enthalten, das durch ein Gleichheitszeichen getrennt ist und ein Gewicht angibt, das bei der Content-Aushandlung verwendet werden soll. Beispielsweise kann ein Browser angeben, dass er Informationen in Deutsch oder Englisch akzeptiert, wobei Deutsch bevorzugt wird, indem der q-Wert für de höher als der von en gesetzt wird, wie folgt:
Accept-Language: de; q=1.0, en; q=0.5
Größenbeschränkungen
Der Standard legt keine Beschränkungen für die Größe jedes Header-Feldnamens oder -Werts oder für die Anzahl der Felder fest. Die meisten Server, Clients und Proxy-Software legen jedoch aus praktischen und Sicherheitsgründen einige Beschränkungen fest. Beispielsweise begrenzt der Apache 2.3-Server standardmäßig die Größe jedes Felds auf 8.190 Byte, und es dürfen höchstens 100 Headerfelder in einer einzelnen Anfrage vorhanden sein.
Standard-Anfragefelder
| Name | Beschreibung | Beispiel | Status | Standard |
|---|---|---|---|---|
| A-IM | Akzeptable Instanzmanipulationen für die Anfrage. | A-IM: feed |
Permanent | RFC 3229 |
| Accept | Medientyp(en), der/die für die Antwort akzeptabel ist/sind. Siehe Content Negotiation. | Accept: text/html |
Permanent | RFC 2616, 7231 |
| Accept-Charset | Zeichensätze, die akzeptabel sind. | Accept-Charset: utf-8 |
Permanent | RFC 2616 |
| Accept-Datetime | Akzeptable Version in der Zeit. | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT |
Provisorisch | RFC 7089 |
| Accept-Encoding | Liste der akzeptablen Kodierungen. Siehe HTTP-Komprimierung. | Accept-Encoding: gzip, deflate |
Permanent | RFC 2616, 7231 |
| Accept-Language | Liste der akzeptablen menschlichen Sprachen für die Antwort. Siehe Content Negotiation. | Accept-Language: en-US |
Permanent | RFC 2616, 7231 |
| Access-Control-Request-Method, Access-Control-Request-Headers |
Initiiert eine Anfrage für die gemeinsame Nutzung von Ressourcen ursprungsübergreifend mit Origin (siehe unten). | Access-Control-Request-Method: GET |
Permanent: Standard | |
| Authorization | Authentifizierungsdaten für die HTTP-Authentifizierung. | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Permanent | |
| Cache-Control | Wird verwendet, um Direktiven anzugeben, die von allen Caching-Mechanismen entlang der Anfrage-Antwort-Kette befolgt werden müssen. | Cache-Control: no-cache |
Permanent | |
| Verbindung | Steuerungsoptionen für die aktuelle Verbindung und Liste der Hop-by-Hop-Anfragefelder.Darf nicht mit HTTP/2 verwendet werden. | Connection: keep-aliveConnection: Upgrade |
Permanent | |
| Content-Encoding | Die Art der Kodierung, die für die Daten verwendet wird. Siehe HTTP-Komprimierung. | Content-Encoding: gzip |
Permanent | |
| Content-Length | Die Länge des Anfrage-Content in Oktetten (8-Bit-Bytes). | Content-Length: 348 |
Permanent | |
| Content-MD5 | Eine Base64-kodierte binäre MD5-Summe des Inhalts des Anfrage-Content. | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Veraltet | |
| Content-Type | Der Medientyp des Content der Anfrage (wird mit POST- und PUT-Anfragen verwendet). | Content-Type: application/x-www-form-urlencoded |
Permanent | |
| Cookie | Ein HTTP-Cookie, das zuvor vom Server mit Set-Cookie (siehe unten) gesendet wurde. | Cookie: $Version=1; Skin=new; |
Permanent: Standard | |
| Date | Datum und Uhrzeit, zu der die Nachricht erstellt wurde (im “HTTP-Date”-Format, wie in RFC 7231 Datums-/Uhrzeitformate definiert). | Date: Tue, 15 Nov 1994 08:12:31 GMT |
Permanent | |
| Expect | Gibt an, dass bestimmte Serververhalten vom Client benötigt werden. | Expect: 100-continue |
Permanent | |
| Forwarded | Offenlegung ursprünglicher Informationen eines Clients, der sich über einen HTTP-Proxy mit einem Webserver verbindet. | Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 Forwarded: for=192.0.2.43, for=198.51.100.17 |
Permanent | |
| From | Die E-Mail-Adresse des Benutzers, der die Anfrage stellt. | From: user@example.com |
Permanent | |
| Host | Der Domänenname des Servers (für virtuelles Hosting) und die TCP-Portnummer, an der der Server lauscht. Die Portnummer kann weggelassen werden, wenn der Port der Standardport für den angeforderten Dienst ist. Obligatorisch seit HTTP/1.1. Wenn die Anfrage direkt in HTTP/2 generiert wird, sollte sie nicht verwendet werden. | Host: en.wikipedia.org:8080Host: en.wikipedia.org |
Permanent | |
| HTTP2-Settings | Eine Anfrage, die von HTTP/1.1 auf HTTP/2 aktualisiert, MUSS genau ein HTTP2-Setting Headerfeld enthalten. Das HTTP2-Settings Headerfeld ist ein verbindungsspezifisches Headerfeld, das Parameter enthält, die die HTTP/2-Verbindung steuern, die in Erwartung der Annahme der Anfrage durch den Server zur Aktualisierung bereitgestellt werden. |
HTTP2-Settings: token64 |
Permanent: Standard | |
| If-Match | Führe die Aktion nur aus, wenn die vom Client bereitgestellte Entität mit derselben Entität auf dem Server übereinstimmt. Dies gilt hauptsächlich für Methoden wie PUT, um eine Ressource nur dann zu aktualisieren, wenn sie seit der letzten Aktualisierung durch den Benutzer nicht geändert wurde. | If-Match: "737060cd8c284d8af7ad3082f209582d" |
Permanent | |
| If-Modified-Since | Ermöglicht die Rückgabe eines 304 Not Modified, wenn der Content unverändert ist. | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
Permanent | |
| If-None-Match | Ermöglicht die Rückgabe eines 304 Not Modified, wenn der Content unverändert ist, siehe HTTP ETag. | If-None-Match: "737060cd8c284d8af7ad3082f209582d" |
Permanent | |
| If-Range | Wenn die Entität unverändert ist, sende mir die Teile, die mir fehlen; andernfalls sende mir die gesamte neue Entität. | If-Range: "737060cd8c284d8af7ad3082f209582d" |
Permanent | |
| If-Unmodified-Since | Sende die Antwort nur, wenn die Entität seit einem bestimmten Zeitpunkt nicht geändert wurde. | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
Permanent | |
| Max-Forwards | Begrenze die Anzahl der Male, die die Nachricht über Proxys oder Gateways weitergeleitet werden kann. | Max-Forwards: 10 |
Permanent | |
| Origin | Initiiert eine Anfrage für die gemeinsame Nutzung von Ressourcen ursprungsübergreifend (fordert vom Server Access-Control-* Antwortfelder an). | Origin: http://www.example-social-network.com |
Permanent: Standard | |
| Pragma | Implementierungsspezifische Felder, die an beliebiger Stelle entlang der Anfrage-Antwort-Kette verschiedene Auswirkungen haben können. | Pragma: no-cache |
Permanent | |
| Prefer | Ermöglicht es dem Client, anzufordern, dass bestimmte Verhaltensweisen von einem Server bei der Bearbeitung einer Anfrage angewendet werden. | Prefer: return=representation |
Permanent | RFC 7240 |
| Proxy-Authorization | Authentifizierungsdaten für die Verbindung zu einem Proxy. | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Permanent | |
| Range | Fordere nur einen Teil einer Entität an. Bytes werden ab 0 nummeriert. Siehe Byte-Serving. | Range: bytes=500-999 |
Permanent | |
| Referer | Dies ist die Adresse der vorherigen Webseite, von der aus ein Link zu der aktuell angeforderten Seite verfolgt wurde. (Das Wort “Referrer” wurde im RFC sowie in den meisten Implementierungen so falsch geschrieben, dass es sich zu einer Standardverwendung entwickelt hat und als korrekte Terminologie gilt) | Referer: http://en.wikipedia.org/wiki/Main_Page |
Permanent | |
| TE | Die Transferkodierungen, die der User-Agent zu akzeptieren bereit ist: Es können die gleichen Werte wie für das Antwort-Headerfeld Transfer-Encoding verwendet werden, zuzüglich des Werts “trailers” (bezogen auf die “chunked”-Transfermethode), um den Server zu benachrichtigen, dass er erwartet, zusätzliche Felder im Trailer nach dem letzten, Null-Byte-Chunk zu empfangen. Nur trailers wird in HTTP/2 unterstützt. |
TE: trailers, deflate |
Permanent | |
| Trailer | Der allgemeine Feldwert Trailer gibt an, dass die angegebene Menge von Headerfeldern im Trailer einer Nachricht vorhanden ist, die mit Chunked Transfer Coding kodiert wurde. | Trailer: Max-Forwards |
Permanent | |
| Transfer-Encoding | Die Form der Kodierung, die verwendet wird, um die Entität sicher an den Benutzer zu übertragen. Derzeit definierte Methoden sind: chunked, compress, deflate, gzip, identity. Darf nicht mit HTTP/2 verwendet werden. | Transfer-Encoding: chunked |
Permanent | |
| User-Agent | Die User-Agent-Zeichenfolge des User-Agents. | User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 |
Permanent | |
| Upgrade | Fordere den Server auf, auf ein anderes Protokoll zu aktualisieren. Darf nicht in HTTP/2 verwendet werden. | Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket |
Permanent | |
| Via | Informiert den Server über Proxys, über die die Anfrage gesendet wurde. | Via: 1.0 fred, 1.1 example.com (Apache/1.1) |
Permanent | |
| Warning | Eine allgemeine Warnung vor möglichen Problemen mit dem Entität-Content. | Warning: 199 Miscellaneous warning |
Permanent |
Quelle: Liste der HTTP-Headerfelder, https://en.wikipedia.org/wiki/List_of_HTTP_header_fields [Abgerufen am 18. November 2021]
