HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, mit einer Nachricht in einer Anfrage oder Antwort zusätzliche Informationen zu übermitteln. In HTTP/1.X ist ein Header ein Name ohne Berücksichtigung der Groß- und Kleinschreibung, gefolgt von einem Doppelpunkt, anschließend optionalen Leerzeichen, die ignoriert werden, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header bei der Anzeige in Entwicklertools kleingeschrieben (accept: */*) und für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt vorangestellt (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden in der Vergangenheit mit dem Präfix X- verwendet, aber diese Konvention wurde 2012 aufgrund der Schwierigkeiten, die sie verursachte, wenn nicht standardisierte Felder in RFC 6648 standardisiert wurden, als veraltet eingestuft; andere sind in der IANA-Registrierung für HTTP-Feldnamen aufgeführt, deren ursprünglicher Inhalt in RFC 4229 definiert wurde. Die IANA-Registrierung führt Header auf, einschließlich Informationen zu ihrem Status.

Header können nach ihren Kontexten gruppiert werden:

Anfrage-Header: Enthalten weitere Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.
Antwort-Header: Enthalten zusätzliche Informationen über die Antwort, etwa ihren Speicherort oder den Server, der sie bereitstellt.
Repräsentations-Header: Enthalten Informationen über den Body der Ressource, etwa ihren MIME-Typ oder die angewendete Kodierung/Komprimierung.
Payload-Header: Enthalten repräsentationsunabhängige Informationen über Payload-Daten, einschließlich der Inhaltslänge und der für den Transport verwendeten Kodierung.

Header können auch danach gruppiert werden, wie Proxys sie behandeln:

End-to-End-Header: Diese Header müssen an den endgültigen Empfänger der Nachricht übertragen werden: an den Server bei einer Anfrage oder an den Client bei einer Antwort. Zwischenliegende Proxys müssen diese Header unverändert erneut übertragen und Caches müssen sie speichern.
Hop-by-Hop-Header: Diese Header sind nur für eine einzelne Verbindung auf Transportebene relevant und dürfen nicht von Proxys erneut übertragen oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mit dem Header Connection gesetzt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource verwendet werden soll.
Authorization: Enthält die Anmeldedaten zur Authentifizierung eines User-Agents gegenüber einem Server.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden soll.
Proxy-Authorization: Enthält die Anmeldedaten zur Authentifizierung eines User-Agents gegenüber einem Proxy-Server.

Caching

Age: Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache verbracht hat.
Cache-Control: Direktiven für Caching-Mechanismen in Anfragen und Antworten.
Clear-Site-Data: Löscht Browsing-Daten (z. B. Cookies, Speicher, Cache), die der anfragenden Website zugeordnet sind.
Expires: Das Datum/die Uhrzeit, nach dem bzw. der die Antwort als veraltet gilt.
No-Vary-Search: Gibt eine Reihe von Regeln an, die definieren, wie die Abfrageparameter einer URL den Cache-Abgleich beeinflussen. Diese Regeln legen fest, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Bedingungen

Last-Modified: Das Datum der letzten Änderung der Ressource, das zum Vergleichen mehrerer Versionen derselben Ressource verwendet wird. Es ist weniger genau als ETag, in einigen Umgebungen aber einfacher zu berechnen. Bedingte Anfragen mit If-Modified-Since und If-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.
ETag: Eine eindeutige Zeichenfolge, die die Version der Ressource identifiziert. Bedingte Anfragen mit If-Match und If-None-Match verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.
If-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.
If-None-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit keinem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (bei sicheren Anfragen) oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine vorhanden ist.