HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort zu übermitteln. In HTTP/1.X ist ein Header ein nicht auf Groß- oder Kleinschreibung achtender Name, gefolgt von einem Doppelpunkt, dann optionalem Leerraum, der ignoriert wird, und schließlich von seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header, wenn sie in den Entwickler-Tools angezeigt werden, in Kleinbuchstaben dargestellt (accept: */*) und für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt am Anfang versehen (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden historisch mit einem X--Präfix verwendet, aber diese Konvention wurde 2012 wegen der Unannehmlichkeiten, die sie verursachte, als nicht standardisierte Felder zu Standardfeldern wurden, in RFC 6648 als veraltet erklärt; andere sind im IANA HTTP Field Name Registry aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header inklusive Informationen über ihren Status auf.

Header können nach ihren Kontexten gruppiert werden:

Request-Header

Enthalten mehr Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.

Response-Header

Beinhaltet zusätzliche Informationen über die Antwort, wie etwa ihren Standort oder über den Server, der sie bereitstellt.

Darstellungs-Header

Enthalten Informationen über den Körper der Ressource, wie ihren MIME-Typ oder die angewendete Kodierung/Kompression.

Payload-Header

Enthalten darstellungsunabhängige Informationen über Nutzdaten, 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 weitergeleitet werden: den Server bei einer Anfrage oder den Client bei einer Antwort. Zwischenzeitliche Proxys müssen diese Header unverändert weiterleiten und Caches müssen sie speichern.

Hop-by-hop-Header

Diese Header sind nur für eine einzelne Transportebene-Verbindung von Bedeutung und dürfen nicht von Proxys weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mit dem Connection-Header festgelegt werden dürfen.

Authentifizierung

WWW-Authenticate

Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden sollte.

Authorization

Enthält die Anmeldedaten, um einen Benutzeragenten mit einem Server zu authentifizieren.

Proxy-Authenticate

Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource hinter einem Proxyserver verwendet werden sollte.

Proxy-Authorization

Enthält die Anmeldedaten, um einen Benutzeragenten bei einem Proxyserver zu authentifizieren.

Caching

Age

Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache verbracht hat.

Cache-Control

Direktiven für Caching-Mechanismen in sowohl Anfragen als auch Antworten.

Clear-Site-Data

Löscht Browserverlaufsdaten (z.B. Cookies, Speicher, Cache) der anfragenden Website.

Expires

Das Datum/Uhrzeit, nach der die Antwort als veraltet angesehen wird.

Gibt einen Satz von Regeln an, die definieren, wie die Abfrageparameter einer URL das Cache-Matching beeinflussen. Diese Regeln bestimmen, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Einträge im Browser-Cache gespeichert werden sollte.

Bedingungen

Last-Modified

Das Datum der letzten Änderung der Ressource, verwendet zum Vergleich mehrerer Versionen derselben Ressource. Es ist weniger genau als ETag, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anfragen, die If-Modified-Since und If-Unmodified-Since verwenden, nutzen diesen Wert, um das Verhalten der Anfrage zu ändern.

ETag

Ein eindeutiger String, der die Version der Ressource identifiziert. Bedingte Anfragen, die If-Match und If-None-Match verwenden, nutzen 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 nicht mit einem 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 existiert.

If-Modified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur zu übertragen, wenn der Cache veraltet ist.

If-Unmodified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies gewährleistet die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen, oder um ein optimistisches Steuerungssystem für die gleichzeitige Modifikation beim Ändern bestehender Dokumente zu implementieren.

Vary

Bestimmt, wie Anforderungsheader verglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine frische vom Ursprungsserver anzufordern.

Verbindungsverwaltung

Connection

Steuert, ob die Netzwerkverbindung offen bleibt, nachdem die aktuelle Transaktion abgeschlossen ist.

Keep-Alive

Steuert, wie lange eine persistente Verbindung offen bleiben sollte.

Inhaltsverhandlung

Für weitere Details siehe den Artikel zur Inhaltsverhandlung.

Accept

Informiert den Server über die Typen von Daten, die zurückgesendet werden können.

Accept-Encoding

Der Kodierungsalgorithmus, normalerweise ein Kompressionsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.

Accept-Language

Informiert den Server über die menschliche Sprache, die der Server zurücksenden soll. Dies ist ein Hinweis und möglicherweise nicht vollständig unter der Kontrolle des Benutzers: Der Server sollte immer darauf achten, keine explizite Benutzerwahl zu überschreiben (wie das Auswählen einer Sprache aus einem Dropdown-Menü).

Accept-Patch

Ein Anfrageinhalt-Verhandlungsantwort-Header, der angibt, welchen Medientyp der Server in einer PATCH-Anfrage verstehen kann.

Accept-Post

Ein Anfrageinhalt-Verhandlungsantwort-Header, der angibt, welchen Medientyp der Server in einer POST-Anfrage verstehen kann.

Steuerungen

Expect

Gibt Erwartungen an, die der Server erfüllen muss, um die Anfrage ordnungsgemäß zu bearbeiten.

Max-Forwards

Bei der Verwendung von TRACE gibt sie die maximale Anzahl von Hops an, die die Anfrage durchführen kann, bevor sie an den Absender zurückgespiegelt wird.

Cookies

Enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem Set-Cookie-Header gesendet wurden.

Sendet Cookies vom Server an den Benutzeragenten.

CORS

Für weitere Informationen siehe die CORS-Dokumentation.

Access-Control-Allow-Credentials

Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Anmeldeflag wahr ist.

Access-Control-Allow-Headers

Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header beim tatsächlichen Anfordern verwendet werden können.

Access-Control-Allow-Methods

Gibt die Methoden an, die beim Zugriff auf die Ressource in Reaktion auf eine Preflight-Anfrage erlaubt sind.

Access-Control-Allow-Origin

Gibt an, ob die Antwort geteilt werden kann.

Access-Control-Expose-Headers

Gibt an, welche Header als Teil der Antwort offengelegt werden können, indem ihre Namen aufgelistet werden.

Access-Control-Max-Age

Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage im Cache bleiben können.

Access-Control-Request-Headers

Wird bei der Ausgabe einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Header beim tatsächlichen Anfordern verwendet werden.

Access-Control-Request-Method

Wird bei der Ausgabe einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Methode beim tatsächlichen Anfordern verwendet wird.

Origin

Gibt an, woher ein Fetch stammt.

Timing-Allow-Origin

Gibt Ursprünge an, die es erlauben, Werte von Attributen zu sehen, die über Funktionen der Ressourcen-Zeitmessungs-API abgerufen wurden, die andernfalls aufgrund von Herkunftsbeschränkungen als Null gemeldet werden würden.

Downloads

Content-Disposition

Gibt an, ob die übertragene Ressource inline angezeigt werden sollte (Standardverhalten ohne den Header), oder ob sie wie ein Download behandelt werden und der Browser ein "Speichern unter"-Dialog anzeigen sollte.

Integritätsprüfungen

Content-Digest Experimentell

Bietet einen Digest des Stroms von Oktetten, der in einer HTTP-Nachricht (dem Nachrichteninhalt) eingerahmt ist, abhängig von Content-Encoding und Content-Range.

Repr-Digest Experimentell

Bietet einen Digest der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zum Content-Digest berücksichtigt der Digest nicht Content-Encoding oder Content-Range.

Want-Content-Digest Experimentell

Gibt den Wunsch nach einem Content-Digest-Header an. Es ist das Content--Analogon zu Want-Repr-Digest.

Want-Repr-Digest Experimentell

Gibt den Wunsch nach einem Repr-Digest-Header an. Es ist das Repr--Analogon zu Want-Content-Digest.

Integritätspolitik

Integrity-Policy

Stellt sicher, dass alle vom Benutzeragenten geladenen Ressourcen (eines bestimmten Typs) Subresource Integrity-Garantien haben.

Integrity-Policy-Report-Only

Berichtet über Ressourcen, die vom Benutzeragenten geladen werden und die Subresource Integrity-Garantien verletzen würden, wenn die Integritätspolitik durchgesetzt würde (unter Verwendung des Integrity-Policy-Headers).

Nachrichtenkörperinformationen

Content-Length

Die Größe der Ressource in dezimaler Anzahl von Bytes.

Content-Type

Gibt den Medientyp der Ressource an.

Content-Encoding

Wird verwendet, um den Kompressionsalgorithmus zu spezifizieren.

Content-Language

Beschreibt die menschliche(n) Sprache(n), die für das Publikum bestimmt sind, so dass ein Benutzer differenzieren kann, entsprechend der eigenen bevorzugten Sprache des Benutzers.

Content-Location

Gibt einen alternativen Standort für die zurückgegebenen Daten an.

Präferenzen

Präferenzen können von Clients in Anfragen gesendet werden, um optionale Verhaltensweisen für Anfragen und Antworten anzugeben. Die Serverantwort kann angeben, ob eine Präferenz angewandt wurde, in Fällen, in denen es ansonsten für den Client unklar wäre. Browser haben keine native Handhabung zum Senden von Präferenzen über diese Header; sie werden in speziellen, implementierungsspezifischen Clients verwendet.

Prefer

Gibt Präferenzen für spezifisches Serververhalten während der Anfragenverarbeitung an. Beispielsweise kann es einen minimalen Antwortinhalt (return=minimal) oder eine asynchrone Verarbeitung (respond-async) anfordern. Der Server verarbeitet die Anfrage normal, wenn der Header nicht unterstützt wird.

Preference-Applied

Informiert den Client, welche Präferenzen, die im Prefer-Header angegeben sind, vom Server angewendet wurden. Es ist ein nur-Response-Header, der Transparenz über die Präferenzverarbeitung bietet.

Proxys

Forwarded

Enthält Informationen von der Client-Seite der Proxy-Server, die verändert oder verloren gehen, wenn ein Proxy im Anforderungspfad involviert ist.

Via

Hinzugefügt von Proxys, sowohl Vorwärts- als auch Rückwärtsproxys, und kann in den Anforderungs- und Antwort-Headern erscheinen.

Bereichsanfragen

HTTP-Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Mediaplayer, die zufälligen Zugriff unterstützen, Datenwerkzeuge, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Download-Manager, die es den Benutzern ermöglichen, einen Download zu pausieren und fortzusetzen.

Accept-Ranges

Gibt an, ob der Server Bereichsanfragen unterstützt, und wenn ja, in welcher Einheit die Bereiche angegeben werden können.

Range

Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.

If-Range

Erzeugt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn der angegebene Etag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen aus inkompatiblen Versionen der Ressource zu verhindern.

Content-Range

Gibt an, wo in einer vollständigen Nachricht ein Teil der Nachricht hingehört.

Weiterleitungen

Location

Gibt die URL an, zu der eine Seite weitergeleitet werden soll.

Refresh

Weist den Browser an, die Seite neu zu laden oder zu einer anderen weiterzuleiten. Nimmt denselben Wert wie das meta-Element mit http-equiv="refresh" an.

Anforderungskontext

From

Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden Benutzeragenten steuert.

Host

Gibt den Domänennamen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server lauscht.

Referer

Die Adresse der vorherigen Webseite, von der aus ein Link zur aktuell angeforderten Seite gefolgt wurde.

Referrer-Policy

Bestimmt, welche Referrer-Informationen im Referer-Header mit Anfragen gesendet werden sollten.

User-Agent

Enthält eine charakteristische Zeichenkette, die es den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfordernden Software-Benutzeragenten zu identifizieren.

Antwortkontext

Allow

Listet die Menge der von einer Ressource unterstützten HTTP-Anforderungsmethoden auf.

Server

Enthält Informationen über die Software, die vom Ursprungsserver verwendet wird, um die Anfrage zu bearbeiten.

Sicherheit

Cross-Origin-Embedder-Policy (COEP)

Ermöglicht es einem Server, eine Embedder-Richtlinie für ein bestimmtes Dokument zu deklarieren.

Cross-Origin-Opener-Policy (COOP)

Verhindert, dass andere Domains ein Fenster öffnen oder kontrollieren.

Cross-Origin-Resource-Policy (CORP)

Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch den CORP-Erklärungsartikel.

Content-Security-Policy (CSP)

Kontrolliert Ressourcen, die der Benutzeragent für eine gegebene Seite laden darf.

Content-Security-Policy-Report-Only

Ermöglicht Webentwicklern, mit Richtlinien zu experimentieren, indem sie deren Effekte überwachen, aber nicht erzwingen. Diese Verletzungsberichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.

Expect-CT Veraltet

Ermöglicht es Websites, sich für die Berichtserstattung und Durchsetzung von Certificate Transparency zu entscheiden, um eine Verwendung von fehlgeleiteten Zertifikaten für diese Website zu erkennen.

Permissions-Policy

Bietet einen Mechanismus, um die Verwendung von Browserfunktionen im eigenen Frame einer Website und in <iframe>s, die es einbettet, zu erlauben und zu verweigern.

Reporting-Endpoints Experimentell

Antwort-Header, der es Websitebesitzern ermöglicht, einen oder mehrere Endpunkte anzugeben, an die Fehlerberichte gesendet werden sollen, wie CSP-Verletzungsberichte, Cross-Origin-Opener-Policy-Berichte oder andere generische Verstöße.

Strict-Transport-Security (HSTS)

Erzwingt die Kommunikation über HTTPS statt HTTP.

Upgrade-Insecure-Requests

Sendet ein Signal an den Server, das den Kundenwunsch nach einer verschlüsselten und authentifizierten Antwort ausdrückt, und dass er die upgrade-insecure-requests-Direktive erfolgreich handhaben kann.

X-Content-Type-Options

Deaktiviert das MIME-Sniffing und zwingt den Browser, den im Content-Type angegebenen Typ zu verwenden.

X-Frame-Options (XFO)

Gibt an, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern darf.

X-Permitted-Cross-Domain-Policies

Eine Cross-Domain-Policy-Datei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderen) die Berechtigung erteilen, Daten über Domänen hinweg zu behandeln, die ansonsten aufgrund der Same-Origin-Policy eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header hebt solche Policy-Dateien auf, so dass Clients weiterhin unerwünschte Anfragen blockieren.

X-Powered-By

Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, ohne dass sie der Anwendung oder ihren Besuchern von Nutzen sind. Entfernen Sie diesen Header, um potenzielle Schwachstellen nicht offenzulegen.

X-XSS-Protection

Aktiviert die Filterung von Cross-Site-Scripting.

Fetch-Metadaten-Anforderungsheader

Fetch-Metadaten-Anforderungsheader liefern Informationen über den Kontext, aus dem die Anfrage stammt. Ein Server kann sie nutzen, um Entscheidungen darüber zu treffen, ob eine Anfrage erlaubt wird, basierend darauf, woher die Anfrage kommt und wie die Ressource verwendet wird.

Sec-Fetch-Site

Gibt die Beziehung zwischen dem Ursprung eines Anfrageninitiators und dem Ziel seiner Anfrage an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token mit möglichen Werten cross-site, same-origin, same-site und none ist.

Sec-Fetch-Mode

Gibt den Modus der Anfrage an einen Server an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token mit möglichen Werten cors, navigate, no-cors, same-origin und websocket ist.

Sec-Fetch-User

Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktion ausgelöst wurde oder nicht. Es handelt sich um einen strukturierten Header, dessen Wert ein boolescher Wert ist, sodass die möglichen Werte ?0 für falsch und ?1 für wahr sind.

Sec-Fetch-Dest

Gibt das Ziel der Anfrage an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token mit möglichen Werten audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker und xslt ist.

Die folgenden Anforderungsheader sind nicht streng genommen "Fetch-Metadaten-Anforderungsheader", liefern aber ähnlich Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie nutzen, um sein Caching-Verhalten zu ändern oder die zurückgegebenen Informationen:

Sec-Purpose

Gibt den Zweck der Anfrage an, wenn der Zweck ein anderer ist als die sofortige Verwendung durch den Benutzeragenten. Der Header hat derzeit einen möglichen Wert, prefetch, der angibt, dass die Ressource präemptiv für eine mögliche zukünftige Navigation abgerufen wird.

Service-Worker-Navigation-Preload

Ein Anforderungsheader, der in präemptiven Anfragen gesendet wird, um eine Ressource während des Service-Worker-Bootprozesses zu fetch(). Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server zu informieren, dass eine andere Ressource zurückgegeben werden soll als bei einer normalen fetch()-Operation.

Servergesendete Ereignisse

Reporting-Endpoints

Antwort-Header, der verwendet wird, um Serverendpunkte zu spezifizieren, an die der Browser bei der Verwendung der Reporting-API Warn- und Fehlerberichte senden soll.

Report-To Veraltet Nicht standardisiert

Antwort-Header, der verwendet wird, um Serverendpunkte zu spezifizieren, an die der Browser bei der Verwendung der Reporting-API Warn- und Fehlerberichte senden soll.

Übertragungscodierung

Transfer-Encoding

Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.

TE

Gibt die Übertragungscodierungen an, die der Benutzeragent akzeptieren möchte.

Trailer

Ermöglicht es dem Absender, zusätzliche Felder am Ende einer gestückelten Nachricht hinzuzufügen.

WebSockets

Header, die von der WebSockets-API im WebSocket-Handschlag verwendet werden:

Sec-WebSocket-Accept

Antwort-Header, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung zu wechseln.

Sec-WebSocket-Extensions

In Anfragen zeigt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten WebSocket-Erweiterungen an. In Antworten zeigt er die vom Server aus den Vorlieben des Clients ausgewählte Erweiterung an.

Sec-WebSocket-Key

Anforderungsheader, der einen Schlüssel enthält, der überprüft, dass der Client explizit beabsichtigt, eine WebSocket-Verbindung zu öffnen.

Sec-WebSocket-Protocol

In Anfragen zeigt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten Subprotokolle an. In Antworten zeigt er das vom Server aus den Vorlieben des Clients ausgewählte Subprotokoll an.

Sec-WebSocket-Version

In Anfragen zeigt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn die angeforderte Protokollversion vom Server nicht unterstützt wird, und listet die unterstützten Versionen auf.

Andere

Alt-Svc

Wird verwendet, um alternative Möglichkeiten anzugeben, um diesen Dienst zu erreichen.

Alt-Used

Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.

Date

Enthält das Datum und die Uhrzeit, zu der die Nachricht entstanden ist.

Dieses Entity-Header-Feld bietet eine Möglichkeit, einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML-<link>-Element.

Retry-After

Gibt an, wie lange der Benutzeragent warten sollte, bevor eine Folgeanfrage gestellt wird.

Server-Timing

Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfragen-Antwort-Zyklus.

Service-Worker

Wird in Fetch-Anfragen für das Skriptressource eines Service Workers enthalten. Dieser Header hilft Administratoren beim Protokollieren von Service-Worker-Skriptanfragen zu Überwachungszwecken.

Service-Worker-Allowed

Wird verwendet, um die Pfadbeschränkung aufzuheben, indem dieser Header in der Antwort des Service-Worker-Skripts enthalten ist.

SourceMap

Verlinkt auf eine Source Map, sodass Debugger durch den ursprünglichen Quellcode anstelle von generiertem oder transformiertem Code schritten können.

Upgrade

Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung zu einem anderen Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Er kann beispielsweise von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 zu aktualisieren oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket.

Priority

Gibt einen Hinweis auf die Priorität einer bestimmten Ressourcenanforderung auf einer bestimmten Verbindung. Der Wert kann in einer Anforderung gesendet werden, um die Priorität des Clients anzugeben, oder in einer Antwort, wenn der Server sich entscheidet, die Anforderung neu zu priorisieren.

Experimentelle Header

Aufzeichnungsheader

Die Attribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen - zum Beispiel, wenn ein Nutzer auf eine eingebettete Anzeige einer Seite klickt und dann auf der Anbieterseite den Artikel kauft - und dann auf Berichte über diese Konversionen zuzugreifen. Dies geschieht ohne die Verwendung von Drittanbieter-Cookies, sondern stützt sich auf verschiedene Header, um Quellen und Trigger zu registrieren, die zu einer Konversion führen.

Attribution-Reporting-Eligible

Wird verwendet, um anzuzeigen, dass die Antwort, die der aktuellen Anfrage entspricht, berechtigt ist, um an der Attributionsberichterstattung teilzunehmen, indem entweder eine Attribution-Quelle oder ein -Trigger registriert wird.

Attribution-Reporting-Register-Source

Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthält, verwendet, um eine Attribution-Quelle zu registrieren.

Attribution-Reporting-Register-Trigger

Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthält, verwendet, um einen Attribution-Trigger zu registrieren.

Client-Hints

HTTP-Client-Hints sind eine Sammlung von Anforderungs-Headern, die nützliche Informationen über den Client wie Gerätetyp und Netzwerkbedingungen bereitstellen und es Servern ermöglichen, das Gelieferte für diese Bedingungen zu optimieren.

Server fordern proaktiv die Client-Hint-Header an, an denen sie interessiert sind, indem sie Accept-CH verwenden. Der Client kann dann entscheiden, ob die angeforderten Header in nachfolgenden Anfragen enthalten werden sollen.

Accept-CH

Server können die Unterstützung von Client-Hints über das Accept-CH-Header-Feld oder ein gleichwertiges HTML-<meta>-Element mit http-equiv-Attribut bewerben.

Critical-CH Experimentell

Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client-Hints auch kritische Client-Hints sind.

Die verschiedenen Kategorien von Client-Hints sind unten aufgeführt.

User-Agent-Client-Hints

Die UA-Client-Hints sind Anforderungs-Header, die Informationen über den Benutzeragenten, die Plattform/Architektur, auf der er läuft, und Benutzerpräferenzen, die auf dem Benutzeragenten oder der Plattform eingestellt sind, bereitstellen:

Sec-CH-UA Experimentell

Benutzeragenten-Marke und Version.

Sec-CH-UA-Arch Experimentell

Plattformarchitektur des Benutzeragenten.

Sec-CH-UA-Bitness Experimentell

CPU-Architektur-Bitness des Benutzeragenten (zum Beispiel "64" bit).

Sec-CH-UA-Form-Factors Experimentell

Formfaktoren des Benutzeragenten, die beschreiben, wie der Benutzer mit dem Benutzeragenten interagiert.

Sec-CH-UA-Full-Version Veraltet

Vollständige Versionszeichenkette des Benutzeragenten.

Sec-CH-UA-Full-Version-List Experimentell

Vollständige Version für jede Marke in der Markenliste des Benutzeragenten.

Sec-CH-UA-Mobile Experimentell

Der Benutzeragent läuft auf einem mobilen Gerät oder bevorzugt generell eine "mobile" Benutzererfahrung.

Sec-CH-UA-Model Experimentell

Gerätemodell des Benutzeragenten.

Sec-CH-UA-Platform Experimentell

Betriebssystem/Plattform des Benutzeragenten.

Sec-CH-UA-Platform-Version Experimentell

Betriebssystemversion des Benutzeragenten.

Sec-CH-UA-WoW64 Experimentell

Gibt an, ob das Benutzeragentenprogramm im 32-Bit-Modus auf 64-Bit-Windows läuft.

Sec-CH-Prefers-Color-Scheme Experimentell

Präferenz des Benutzers für ein dunkles oder helles Farbschema.

Sec-CH-Prefers-Reduced-Motion Experimentell

Präferenz des Benutzers für weniger Animationen und Inhaltslayoutverschiebungen.

Sec-CH-Prefers-Reduced-Transparency Experimentell

Der Anforderungs-Header gibt die Präferenz des Benutzeragenten für reduzierte Transparenz an.

Hinweis: Benutzeragenten-Client-Hints sind in fenced frames nicht verfügbar, da sie sich auf die Permissions-Policy-Delegation stützen, die zum Datenleck genutzt werden könnte.

Geräte-Client-Hints

Content-DPR Veraltet Nicht standardisiert

Antworten-Header, der verwendet wird, um das Bildgerät-zu-Pixel-Verhältnis (DPR) in Anfragen zu bestätigen, bei denen der Bildschirm-DPR-Client-Hint verwendet wurde, um eine Bildressource auszuwählen.

Device-Memory

Ungefähre Menge des verfügbaren RAM-Speichers des Clients. Dies ist Teil der Device Memory API.

DPR Veraltet Nicht standardisiert

Anforderungs-Header, der das Geräte-Pixelverhältnis des Clients angibt (die Anzahl physischer Gerätepixel für jedes CSS-Pixel).

Viewport-Width Veraltet Nicht standardisiert

Anforderungs-Header, der die Layout-Sichtfensterbreite des Clients in CSS-Pixeln angibt.

Width Veraltet Nicht standardisiert

Anforderungs-Header, der die gewünschte Ressourcenbreite in physischen Pixeln angibt (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hints

Netzwerk-Client-Hints ermöglichen es einem Server, zu entscheiden, welche Informationen basierend auf der Benutzerwahl und Netzwerkbandbreite und -latenz gesendet werden.

Ungefähre Bandbreite der Client-Verbindung zum Server, in Mbit/s. Dies ist Teil der Network Information API.

ECT Experimentell

Der effektive Verbindungstyp ("Netzwerkprofil"), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.

RTT Experimentell

Round-Trip-Zeit (RTT) auf Anwendungsebene in Millisekunden, die die Serververarbeitungszeit einschließt. Dies ist Teil der Network Information API.

Save-Data Experimentell

Ein String on, der die Präferenz des Benutzeragenten für eine reduzierte Datennutzung anzeigt.

Kompressionswörterbuch-Transport

Kompressionswörterbuch-Transport ist eine Möglichkeit, ein gemeinsam genutztes Kompressionswörterbuch zu verwenden, um die Übertragungsgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch in der Brotli-Komprimierung oder Zstandard-Komprimierung zu verwenden.

Available-Dictionary Experimentell

Ein Browser kann diesen Anforderungs-Header verwenden, um das beste Wörterbuch anzugeben, das er für die Kompression durch den Server verfügbar hat.

Dictionary-ID Experimentell

Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource verfügbar hat und der Server eine id für das Wörterbuch im Use-As-Dictionary-Header bereitgestellt hat. Anfragen nach Ressourcen, die das Wörterbuch verwenden können, haben einen Available-Dictionary-Header und die vom Server bereitgestellte Wörterbuch-id im Dictionary-ID-Header.

Use-As-Dictionary Experimentell

Listet die Übereinstimmungskriterien auf, für die das Wörterbuch in zukünftigen Anfragen verwendet werden kann.

Datenschutz

DNT Veraltet Nicht standardisiert

Anforderungs-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Veraltet zugunsten der Global Privacy Control (GPC), die den Servern über den Sec-GPC-Header mitgeteilt wird und für Clients über navigator.globalPrivacyControl zugänglich ist.

Tk Veraltet Nicht standardisiert

Antwort-Header, der den Tracking-Status angibt, der für die entsprechende Anfrage gilt. Wird in Verbindung mit DNT verwendet.

Sec-GPC Nicht standardisiert Experimentell

Gibt an, ob der Benutzer einer Website oder einem Dienst zustimmt, seine persönlichen Informationen an Dritte zu verkaufen oder zu teilen.

Sicherheit

Origin-Agent-Cluster Experimentell

Antwort-Header, der verwendet wird, um anzuzeigen, dass das zugehörige Document in einem origin-gebundenen Agent-Cluster platziert werden sollte. Diese Isolierung ermöglicht es Benutzeragenten, implementierungsspezifische Ressourcen für Agent-Cluster, wie Prozesse oder Threads, effizienter zuzuweisen.

Servergesendete Ereignisse

NEL Experimentell

Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Netzwerkfehlerberichtspolitik zu deklarieren.

Topics API

Die Topics API stellt einen Mechanismus bereit, mit dem Entwickler Anwendungsfälle wie interessenbasierte Werbung (IBA) implementieren können. Weitere Informationen finden Sie in der Topics API-Dokumentation.

Observe-Browsing-Topics Experimentell Nicht standardisiert

Antwort-Header, der verwendet wird, um Themen von Interesse zu kennzeichnen, die aus der URL einer aufrufenden Seite abgeleitet wurden, wie sie in der Antwort auf eine Anfrage beobachtet wurden, die durch ein Feature, das die Topics API aktiviert.

Sec-Browsing-Topics Experimentell Nicht standardisiert

Anforderungs-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Ad-Tech-Plattform verwendet werden, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.

Andere

Accept-Signature Experimentell

Ein Client kann das Accept-Signature-Header-Feld senden, um die Absicht anzuzeigen, von verfügbaren Signaturen zu profitieren und anzugeben, welche Arten von Signaturen es unterstützt.

Early-Data Experimentell

Gibt an, dass die Anforderung in TLS-Frühdaten übermittelt wurde.

Set-Login Experimentell

Antwort-Header wird von einem föderierten Identitätsanbieter (IdP) gesendet, um seinen Anmeldestatus festzulegen, also zu klären, ob Benutzer beim IdP im aktuellen Browser angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM-API verwendet.

Signature Experimentell

Das Signature-Header-Feld überträgt eine Liste von Signaturen für einen Austausch, wobei jede von Informationen begleitet wird, wie die Autorität dieser Signatur bestimmt und aufgefrischt werden kann.

Signed-Headers Experimentell

Das Signed-Headers-Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur einzuschließen sind.

Speculation-Rules Experimentell

Liefert eine Liste von URLs, die auf Textressourcen zeigen, die Spekulationsregel-JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregelsatz des Dokuments hinzugefügt.

Sec-Speculation-Tags Experimentell

Enthält einen oder mehrere Tag-Werte der Spekulationsregeln, die zu der Spekulation führten, sodass ein Server identifizieren kann, welche Regel(n) eine Spekulation verursachte(n) und sie möglicherweise blockieren könnte(n).

Supports-Loading-Mode Experimentell

Wird von einem Navigationstarget gesetzt, um die Verwendung verschiedener risikoreicher Lademodi zu aktivieren. Zum Beispiel erfordert das Prerendering aus Drittländern einen Supports-Loading-Mode-Wert von credentialed-prerender.

Nicht-standardisierte Header

X-Forwarded-For Nicht standardisiert

Identifiziert die ursprünglichen IP-Adressen eines Clients, der sich über einen HTTP-Proxy oder einen Load Balancer mit einem Webserver verbindet.

X-Forwarded-Host Nicht standardisiert

Identifiziert den ursprünglichen Host, den ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Load Balancer herzustellen.

X-Forwarded-Proto Nicht standardisiert

Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Load Balancer herzustellen.

X-DNS-Prefetch-Control Nicht standardisiert

Steuert das DNS-Vorabrufen, ein Feature, bei dem Browser proaktiv die Namensauflösung für Domänen sowohl von Links ausführen, die der Benutzer möglicherweise wählt, als auch URLs für Elemente, die vom Dokument referenziert werden, einschließlich Bildern, CSS, JavaScript und so weiter.

X-Robots-Tag Nicht standardisiert

Der X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb der öffentlichen Suchmaschinenergebnisse indexiert werden soll. Der Header ist äquivalent zu <meta name="robots">-Elementen.

Veraltete Header

Pragma Veraltet

Implementationsspezifischer Header, der in der gesamten Anfragen-Antwort-Kette verschiedene Effekte haben kann. Wird für die Rückwärtskompatibilität mit HTTP/1.0-Caches verwendet, wo der Cache-Control-Header noch nicht vorhanden ist.

Warning Veraltet

Allgemeine Warninformationen über mögliche Probleme.

Siehe auch