HTTP-Header-Felder sind eine Liste von durch Zeilenvorschübe getrennten HTTP-Daten, die bei jeder HTTP-Anforderung sowohl vom Clientprogramm als auch vom Server gesendet und empfangen werden.
Diese Header sind in der Regel für den Endbenutzer unsichtbar und nur für die Backend-Programme und die Personen, die das Internetsystem warten, sichtbar.
Sie definieren, wie Informationen, die über die Verbindung gesendet/empfangen werden, verschlüsselt werden (wie bei Accept-Encoding), die Sitzungsüberprüfung und Identifizierung des Clients (wie bei Browser-Cookies, IP-Adresse, User-Agent) oder deren Anonymität (VPN- oder Proxy-Masking, User-Agent-Spoofing), wie der Server mit Daten umgehen soll (wie bei Do-Not-Track), das Alter des heruntergeladenen Dokuments, unter anderem.
Allgemeines Format
Die Header-Felder werden nach der Anforderungszeile (im Falle einer HTTP-Anforderungsnachricht) oder der Antwortzeile (im Falle einer HTTP-Antwortnachricht) übertragen, die die erste Zeile einer Nachricht ist.
Kopfzeilenfelder sind durch Doppelpunkte getrennte Schlüssel-Wert-Paare im Klartext-Zeichenfolgenformat, die mit einer Wagenrücklauf- (CR) und einer Zeilenvorschubzeichenfolge (LF) abgeschlossen werden.
Das Ende des Kopfabschnitts wird durch eine leere Feldzeile gekennzeichnet, was zur Übertragung von zwei aufeinanderfolgenden CR-LF-Paaren führt.
In der Vergangenheit konnten lange Linien zu mehreren Linien gefaltet werden; Fortsetzungszeilen werden durch das Vorhandensein eines Leerzeichens (SP) oder eines horizontalen Tabulators (HT) als erstes Zeichen in der nächsten Zeile angezeigt.
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 Header-Felder und das Repository der vorläufigen Registrierungen werden von der IANA geführt.
Zusätzliche Feldnamen und zulässige Werte können von jeder Anwendung definiert werden.
Bei den Namen von Kopfzeilenfeldern wird die Groß-/Kleinschreibung nicht beachtet. Dies steht im Gegensatz zu HTTP-Methodennamen (GET, POST usw.), bei denen zwischen Groß- und Kleinschreibung unterschieden wird. HTTP/2 nimmt einige Einschränkungen für bestimmte Header-Felder vor (siehe unten).
Nicht standardmäßige Header-Felder wurden üblicherweise mit dem Präfix X- gekennzeichnet, aber diese Konvention wurde im Juni 2012 aufgrund der Unannehmlichkeiten verworfen, die sie verursachte, als Nicht-Standard-Felder zum Standard wurden. Eine frühere Einschränkung der Nutzung von Downgraded wurde im März 2013 aufgehoben.
Feldwerte
Einige wenige Felder können Kommentare enthalten (z.B. in User-Agent, Server, Via-Feldern), die von der Software ignoriert werden können. Viele Feldwerte können ein Schlüssel-Wert-Paar der Qualität (q) enthalten, das durch Gleichheitszeichen getrennt ist und eine Gewichtung angibt, die bei der Inhaltsaushandlung verwendet werden soll. Zum Beispiel kann ein Browser anzeigen, dass er Informationen in Deutsch oder Englisch akzeptiert, wobei Deutsch bevorzugt wird, indem er den q-Wert für de höher als den von en setzt, 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 des Namens oder Werts der einzelnen Kopfzeilenfelder oder für die Anzahl der Felder fest.
Die meisten Server, Clients und Proxy-Software legen jedoch aus praktischen und Sicherheitsgründen einige Grenzwerte fest.
Der Apache 2.3-Server begrenzt beispielsweise standardmäßig die Größe jedes Felds auf 8.190 Bytes, und es können maximal 100 Header-Felder in einer einzigen Anforderung vorhanden sein.
Standard-Anforderungsfelder
| Name | Beschreibung | Beispiel | Status | Standard |
|---|---|---|---|---|
| A-IM | Akzeptable Instanzmanipulationen für die Anforderung. | A-IM: feed |
Permanenter | RFC 3229 |
| Annehmen | Medientyp(en), der/die für die Antwort akzeptabel ist/sind. Siehe Inhaltsaushandlung. |
Accept: text/html |
Permanenter | RFC 2616, 7231 |
| Accept-Charset Zeichensätze | , die akzeptabel sind. | Accept-Charset: utf-8 |
Permanenter | RFC 2616 |
| Accept-Datetime | Akzeptable Version in der Zeit. | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT |
Vorläufiger | RFC 7089 |
| Akzeptieren-Kodierung | Liste der akzeptablen Codierungen. Siehe HTTP-Komprimierung. |
Accept-Encoding: gzip, deflate |
Permanenter | RFC 2616, 7231 |
| Accept-Sprache | Liste akzeptabler menschlicher Sprachen für die Antwort. Siehe Inhaltsaushandlung. |
Accept-Language: en-US |
Permanenter | RFC 2616, 7231 |
| access-control-request-method, access-control-request-headers | Initiiert eine Anfrage für die gemeinsame Nutzung von Ressourcen zwischen den Ursprüngen mit Origin (unten). | Access-Control-Request-Method: GET |
Permanent: Standard | |
| Autorisierung | Authentifizierungsdaten für die HTTP-Authentifizierung. | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Permanent sind | |
| Cache-Control | Wird verwendet, um Direktiven anzugeben, die von allen Caching-Mechanismen entlang der Anforderung-Antwort-Kette befolgt werden müssen . | Cache-Control: no-cache |
Permanent sind | |
| Optionen | zur Verbindungssteuerung für die aktuelle Verbindung und Liste der Hop-by-Hop-Anforderungsfelder.Darf nicht mit HTTP/2 verwendet werden. | Connection: keep-aliveConnection: Upgrade |
Permanent sind | |
| Content-Codierung | Der Typ der Codierung, die für die Daten verwendet wird. Siehe HTTP-Komprimierung. |
Content-Encoding: gzip |
Permanent sind | |
| Content-Length | Die Länge des Anforderungstexts in Oktetten (8-Bit-Bytes). | Content-Length: 348 |
Permanent sind | |
| Content-MD5 | Eine Base64-codierte binäre MD5-Summe des Inhalts des Anforderungstexts. | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Obsolet | |
| Content-Type | Der Medientyp des Textkörpers der Anforderung (wird bei POST- und PUT-Anforderungen verwendet). | Content-Type: application/x-www-form-urlencoded |
Permanent sind | |
| Cookie | Ein HTTP-Cookie, das zuvor vom Server mit Set-Cookie (unten) gesendet wurde. | Cookie: $Version=1; Skin=new; |
Permanent: Standard | |
| Datum | Das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde (im Format “HTTP-date”, wie in RFC 7231 Date/Time Formats definiert). | Date: Tue, 15 Nov 1994 08:12:31 GMT |
Permanent sind | |
| Erwarten | Gibt an, dass bestimmte Serververhaltensweisen vom Client benötigt werden. | Expect: 100-continue |
Permanent sind | |
| Weitergeleitet | Geben Sie die ursprünglichen Informationen eines Clients an, der über einen HTTP-Proxy eine Verbindung zu einem Webserver herstellt. | 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 sind | |
| Von | Die E-Mail-Adresse des Benutzers, der die Anfrage stellt. | From: user@example.com |
Permanent sind | |
| Gastgeber | Der Domänenname des Servers (für virtuelles Hosting) und die TCP-Portnummer, an der der Server empfangsbereit ist. Die Portnummer kann weggelassen werden, wenn es sich bei dem Port um den Standardport für den angeforderten Dienst handelt. Verpflichtend seit HTTP/1.1. Wenn die Anforderung direkt in HTTP/2 generiert wird, sollte sie nicht verwendet werden. |
Host: en.wikipedia.org:8080Host: en.wikipedia.org |
Permanent sind | |
| HTTP2-Einstellungen | Eine Anforderung, die ein Upgrade von HTTP/1.1 auf HTTP/2 durchführt, MUSS genau ein HTTP2-Setting Header-Feld enthalten.Das HTTP2-Settings Header-Feld ist ein verbindungsspezifisches Header-Feld, das Parameter enthält, die die HTTP/2-Verbindung steuern und in Erwartung der Annahme der Upgrade-Anforderung durch den Server bereitgestellt werden. |
HTTP2-Settings: token64 |
Permanent: Standard | |
| Wenn-Übereinstimmung | Führen Sie 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 sind | |
| If-Modified-Since | Ermöglicht die Rückgabe von 304 Not Modified , wenn der Inhalt unverändert ist. | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
Permanent sind | |
| If-None-Match | Ermöglicht die Rückgabe von 304 Not Modified , wenn der Inhalt unverändert ist, siehe HTTP ETag. | If-None-Match: "737060cd8c284d8af7ad3082f209582d" |
Permanent sind | |
| If-Bereich | Wenn die Entität unverändert ist, senden Sie mir die Teile, die mir fehlen. Andernfalls senden Sie mir die gesamte neue Entität. | If-Range: "737060cd8c284d8af7ad3082f209582d" |
Permanent sind | |
| If-Unmodified-Since | Sendet 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 sind | |
| Max-Forwards | Begrenzen Sie die Häufigkeit, mit der die Nachricht über Proxys oder Gateways weitergeleitet werden kann. | Max-Forwards: 10 |
Permanent sind | |
| Ursprung | Initiiert eine Anforderung für Cross-Origin Resource Sharing (fragt den Server nach Access-Control-*-Antwortfeldern). | Origin: http://www.example-social-network.com |
Permanent: Standard | |
| Pragma | Implementierungsspezifische Felder, die entlang der Anforderung-Antwort-Kette verschiedene Auswirkungen haben können. | Pragma: no-cache |
Permanent sind | |
| Bevorzugen | Ermöglicht es dem Client, anzufordern, dass bestimmte Verhaltensweisen von einem Server während der Verarbeitung einer Anforderung verwendet werden. | Prefer: return=representation |
Permanenter | RFC 7240 |
| Proxy-Autorisierung | Berechtigungsnachweise für die Verbindung mit einem Proxy. | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Permanent sind | |
| Bereich | Fordern Sie nur einen Teil einer Entität an. Bytes werden ab 0 nummeriert. Siehe Byte-Bereitstellung. |
Range: bytes=500-999 |
Permanent sind | |
| Referrer | Dies ist die Adresse der vorherigen Webseite, von der aus ein Link auf die aktuell angeforderte Seite verfolgt wurde. (Das Wort “Referrer” wurde sowohl im RFC als auch in den meisten Implementierungen falsch geschrieben, bis zu dem Punkt, an dem es zum Standard geworden ist und als korrekte Terminologie angesehen wird.) |
Referer: http://en.wikipedia.org/wiki/Main_Page |
Permanent sind | |
| Die | Übertragungscodierungen, die der Benutzeragent zu akzeptieren bereit ist: Es können die gleichen Werte wie für das Antwortheader-Feld Transfer-Encoding verwendet werden, plus der Wert “trailers” (bezogen auf die Übertragungsmethode “chunked”), um den Server darüber zu informieren, dass er nach dem letzten Chunk mit der Größe Null zusätzliche Felder im Trailer erwartet. Wird nur trailers in HTTP/2 unterstützt. |
TE: trailers, deflate |
Permanent sind | |
| Trailer | Der Wert des allgemeinen Feldes Trailer gibt an, dass der angegebene Satz von Header-Feldern im Trailer einer Nachricht vorhanden ist, die mit Chunked Transfer-Codierung codiert ist. | Trailer: Max-Forwards |
Permanent sind | |
| Übertragungs-Kodierung | Die Form der Codierung, 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 sind | |
| User-Agent | Die User-Agent-Zeichenkette des User-Agenten. | User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 |
Permanent sind | |
| Upgrade | Bitten Sie den Server, ein Upgrade auf ein anderes Protokoll durchzuführen. Darf nicht in HTTP/2 verwendet werden. | Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket |
Permanent sind | |
| Über | Informiert den Server über die Proxys, über die die Anfrage gesendet wurde. | Via: 1.0 fred, 1.1 example.com (Apache/1.1) |
Permanent sind | |
| Warnung | Eine allgemeine Warnung vor möglichen Problemen mit dem Entitätskörper. | Warning: 199 Miscellaneous warning |
Permanent sind |
Quelle: Liste der HTTP-Header-Felder, https://en.wikipedia.org/wiki/List_of_HTTP_header_fields [Abgerufen am 18. November 2021]
