HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer HTTP-Anfrage oder -Antwort auszutauschen. Ein HTTP-Header besteht aus seinem nicht groß-/klein-schreibungssensitiven Namen, gefolgt von einem Doppelpunkt (:), und anschließend von seinem Wert. Leerzeichen vor dem Wert werden ignoriert.

Benutzerdefinierte, proprietäre Header wurden historisch mit einem X- Präfix verwendet, aber diese Konvention wurde im Juni 2012 aufgrund der Unannehmlichkeiten, die entstanden, als nicht-standardisierte Felder zu Standardfeldern wurden, laut RFC 6648 eingestellt; 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, die "permanent" (standarddefiniert), "vorläufig" (neu), "veraltet" (Verwendung nicht empfohlen) oder "obsolet" (nicht mehr in Gebrauch) sein können.

Header können nach ihren Kontexten gruppiert werden:

Request-Header: Enthalten mehr Informationen über die Ressource, die abgerufen werden soll, oder über den Client, der die Ressource anfordert.
Response-Header: Beinhaltet zusätzliche Informationen über die Antwort, wie z.B. ihren Standort oder über den Server, der sie bereitstellt.
Darstellungs-Header: Enthält Informationen über den Körper der Ressource, wie ihren MIME-Typ oder angewandte Kodierung/Kompression.
Payload-Header: Enthält darstellungsunabhängige Informationen über Nutzlastdaten, einschließlich Inhaltslänge und der für den Transport verwendeten Kodierung.

Header können auch nach der Art gruppiert werden, wie Proxies sie handhaben:

End-to-end-Header: Diese Header müssen an den endgültigen Empfänger der Nachricht übermittelt werden: der Server für eine Anfrage oder der Client für eine Antwort. Zwischenproxies müssen diese Header unverändert übertragen und Caches sie speichern.
Hop-by-hop-Header: Diese Header sind nur für eine einzelne Transportebene-Verbindung von Bedeutung und dürfen nicht von Proxies weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mithilfe des Connection Headers festgelegt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden soll.
Authorization: Enthält die Anmeldeinformationen zur Authentifizierung eines Benutzeragents mit einem Server.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden soll.
Proxy-Authorization: Enthält die Anmeldeinformationen zur Authentifizierung eines Benutzeragents mit einem Proxy-Server.

Caching

Age: Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache war.
Cache-Control: Direktiven für Caching-Mechanismen in sowohl Anfragen als auch Antworten.
Clear-Site-Data: Löscht Browsing-Daten (z.B. Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind.
Expires: Das Datum/die Uhrzeit, nach der die Antwort als veraltet betrachtet wird.
No-Vary-Search Experimentell: Gibt eine Reihe von Regeln an, die definieren, wie die Abfrageparameter einer URL das Cache-Abgleichsverfahren beeinflussen. Diese Regeln bestimmen, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Bedingte Anfragen

Last-Modified: Das Datum der letzten Änderung der Ressource, genutzt zum Vergleichen mehrerer Versionen derselben Ressource. Es ist weniger genau als ETag, aber einfacher zu berechnen in einigen Umgebungen. Bedingte Anfragen unter Verwendung von If-Modified-Since und If-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.
ETag: Eine eindeutige Zeichenkette, die die Version der Ressource identifiziert. Bedingte Anfragen unter Verwendung von 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 nicht mit einem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere 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 übermittelt wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur dann zu übermitteln, wenn der Cache veraltet ist.
If-Unmodified-Since: Macht die Anfrage bedingt und erwartet, dass die Ressource nur übermittelt 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 Nebenläufigkeitssteuerungssystem zu implementieren, wenn bestehende Dokumente geändert werden.
Vary: Bestimmt, wie Anforderungsheader abgeglichen werden sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprung-Server anzufordern.

Verbindungsmanagement

Connection: Kontrolliert, ob die Netzwerkverbindung nach Beenden der aktuellen Transaktion geöffnet bleibt.
Keep-Alive: Kontrolliert, wie lange eine persistente Verbindung offen bleiben sollte.

Inhaltsverhandlung

Für weitere Details, konsultieren Sie den Inhaltsverhandlungsartikel.

Accept: Informiert den Server über die Datentypen, die zurückgesandt werden können.
Accept-Encoding: Der Kodierungsalgorithmus, üblicherweise ein Komprimierungsalgorithmus, der auf die zurückgesandte Ressource angewendet werden kann.
Accept-Language: Informiert den Server über die menschliche Sprache, die der Server zurücksenden soll. Dies ist ein Hinweis und nicht notwendigerweise vollständig unter der Kontrolle des Nutzers: der Server sollte stets darauf achten, eine explizite Nutzerwahl (wie das Auswählen einer Sprache aus einem Dropdown-Menü) nicht zu übersteuern.
Accept-Patch: Ein Anfrageinhaltsverhandlung-Antwortheader, der angibt, welchen Medientyp der Server in einer PATCH Anfrage verstehen kann.
Accept-Post: Ein Anfrageinhaltsverhandlung-Antwortheader, der angibt, welchen Medientyp der Server in einer POST Anfrage verstehen kann.

Steuerungen

Expect: Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.
Max-Forwards: Bei Verwendung von TRACE, gibt die maximale Anzahl von Hops an, die die Anfrage ausführen kann, bevor sie an den Absender zurückgespiegelt wird.

Cookies

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

CORS

Für mehr Informationen, beziehen Sie sich auf die CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Berechtigungs-Flag aktiviert ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Voranfrage verwendet, um anzuzeigen, welche HTTP-Header beim Erstellen der tatsächlichen Anfrage verwendet werden können.
Access-Control-Allow-Methods: Spezifiziert die Methoden, die beim Zugriff auf die Ressource als Antwort auf eine Voranfrage 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 Voranfrage zwischengespeichert werden können.
Access-Control-Request-Headers: Wird bei der Ausgabe einer Voranfrage verwendet, um den Server darüber zu informieren, welche HTTP-Header bei Erstellung der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird bei der Ausgabe einer Voranfrage verwendet, um den Server darüber zu informieren, welche HTTP-Methode bei Erstellung der tatsächlichen Anfrage verwendet werden wird.
Origin: Gibt an, woher ein Abruf stammt.
Timing-Allow-Origin: Spezifiziert Herkunftsorte, die die Werte von Attributen sehen dürfen, die durch Funktionen der Resource Timing API abgerufen werden, die ansonsten aufgrund von Cross-Origin-Beschränkungen als null gemeldet würden.

Downloads

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

Integritätsprüfsummen

Content-Digest Experimentell: Stellt eine Prüfsumme des Oktettstroms bereit, der in einer HTTP-Nachricht gerahmt ist (der Nachrichteninhalt), abhängig von Content-Encoding und Content-Range.
Repr-Digest Experimentell: Stellt eine Prüfsumme der ausgewählten Darstellung der Zielressource vor der Übertragung bereit. Anders als bei Content-Digest wird die Prüfsumme nicht unter Berücksichtigung von Content-Encoding oder Content-Range gebildet.
Want-Content-Digest Experimentell: Gibt den Wunsch nach einem Content-Digest Header an. Es ist das Content- Äquivalent zu Want-Repr-Digest.
Want-Repr-Digest Experimentell: Gibt den Wunsch nach einem Repr-Digest Header an. Es ist das Repr- Äquivalent zu Want-Content-Digest.

Nachrichtenkörperinformationen

Content-Length: Die Größe der Ressource in Dezimalzahl von Bytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Wird verwendet, um den Komprimierungsalgorithmus anzugeben.
Content-Language: Beschreibt die für das Publikum vorgesehene menschliche Sprache(n), sodass sie es einem Benutzer ermöglicht, gemäß der eigenen bevorzugten Sprache zu differenzieren.
Content-Location: Gibt einen alternativen Standort für die zurückgegebenen Daten an.

Proxies

Forwarded: Enthält Informationen von der clientseitigen Fassade von Proxy-Servern, die verändert oder verloren gehen, wenn ein Proxy an dem Anforderungsweg beteiligt ist.
Via: Hinzugefügt von Proxies, sowohl Vorwärts- als auch Rückwärts-Proxies, und kann in den Anfrage- und den Antwortheadern erscheinen.

Bereichsabfragen

HTTP Bereichsabfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsabfragen sind nützlich für Anwendungen wie Mediaplayer, die wahlfreien Zugriff unterstützen, Datenwerkzeuge, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Download-Manager, die dem Benutzer das Pausieren und Fortsetzen eines Downloads ermöglichen.

Accept-Ranges: Gibt an, ob der Server Bereichsanfragen unterstützt, und falls ja, in welcher Einheit der Bereich ausgedrückt werden kann.
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 von inkompatiblen Versionen der Ressource zu verhindern.
Content-Range: Gibt an, wo in einer vollständigen Nachrichtenkörpernachricht eine Teilnachricht hingehört.

Umleitungen

Location: Gibt die URL an, zu der eine Seite umgeleitet werden soll.
Refresh: Fordert den Browser auf, die Seite neu zu laden oder zu einer anderen weiterzuleiten. Nimmt denselben Wert an wie das meta Element mit http-equiv="refresh".

Anfragekontext

From: Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden Benutzer-Agenten kontrolliert.
Host: Gibt den Domänennamen des Servers an (für virtuelles Hosting) sowie optional die TCP-Portnummer, auf die der Server hört.
Referer: Die Adresse der vorherigen Webseite, von der ein Link zur derzeit angeforderten Seite gefolgt wurde.
Referrer-Policy: Bestimmt, welche Referrer-Informationen, die im Referer Header gesendet wurden, bei Anfragen einbezogen werden sollen.
User-Agent: Enthält eine charakteristische Zeichenfolge, die die Anwendung, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfragenden Benutzer-Agents identifiziert.

Antwortkontext

Allow: Listet die Reihe der von einer Ressource unterstützten HTTP-Anfragemethoden auf.
Server: Enthält Informationen über die Software, die vom Ursprungsserver zur Bearbeitung der Anfrage verwendet wird.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht es einem Server, eine Einbettungspolitik für ein bestimmtes Dokument zu deklarieren.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domains ein Fenster öffnen/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ärartikel.
Content-Security-Policy (CSP): Kontrolliert, welche Ressourcen der Benutzer-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Ermöglicht es Webentwicklern, mit Richtlinien zu experimentieren, indem sie deren Auswirkungen überwachen, ohne sie durchzusetzen. 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 Berichterstattung und Durchsetzung von Certificate Transparency zu entscheiden, um die Verwendung falsch ausgestellter Zertifikate für diese Seite zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Verwendung von Browserfunktionen innerhalb des Rahmens einer Website zu erlauben oder zu verweigern, und in <iframe>s, die sie einbettet.
Reporting-Endpoints Experimentell: Antwortheader, der es Website-Besitzern ermöglicht, einen oder mehrere Endpunkte anzugeben, die zum Empfangen von Fehlern wie CSP-Verletzungsberichten, Cross-Origin-Opener-Policy-Berichten oder anderen allgemeinen Verletzungen verwendet werden.
Strict-Transport-Security (HSTS): Erzwingt die Kommunikation über HTTPS anstelle von HTTP.
Upgrade-Insecure-Requests: Sendet ein Signal an den Server, das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort zum Ausdruck bringt und dass er den upgrade-insecure-requests Befehl erfolgreich verwalten kann.
X-Content-Type-Options: Deaktiviert MIME-Sniffing und zwingt den Browser, den in 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: Gibt an, ob eine Cross-Domain-Policy-Datei (crossdomain.xml) erlaubt ist. Die Datei kann eine Policy definieren, um Clients wie Adobes Flash Player (mittlerweile obsolet), Adobe Acrobat, Microsoft Silverlight (mittlerweile obsolet) oder Apache Flex zu erlauben, Daten über Domains hinweg zu handhaben, die ansonsten aufgrund der Same-Origin Policy eingeschränkt wären. Für weitere Informationen siehe die Cross-domain Policy File Specification.
X-Powered-By: Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, während es keinen Nutzen für die Anwendung oder deren Besucher bietet. Entfernen Sie diesen Header, um potenzielle Sicherheitslücken nicht offen zu legen.
X-XSS-Protection: Aktiviert das Filtern von Cross-Site-Scripting.

Fetch-Metadaten-Anforderungsheader

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

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprungsort eines Anforderungsinitiators und dem Zielland an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token ist mit möglichen Werten cross-site, same-origin, same-site und none.
Sec-Fetch-Mode: Zeigt den Anfragemodus gegenüber einem Server an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token ist mit möglichen Werten cors, navigate, no-cors, same-origin und websocket.
Sec-Fetch-User: Gibt an, ob eine Navigationsanfrage durch Benutzeraktivierung ausgelöst wurde. Es handelt sich um einen strukturierten Header, dessen Wert ein Boolean ist, sodass mögliche Werte ?0 für false und ?1 für true sind.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token ist mit möglichen Werten audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker und xslt.

Die folgenden Anforderungsheader sind nicht streng genommen "Fetch-Metadaten-Anforderungsheader", liefern aber ebenso Informationen über den Kontext, wie eine Ressource verwendet werden soll. Ein Server kann sie verwenden, um sein Caching-Verhalten zu ändern oder um zu definieren, welche Informationen zurückgegeben werden:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als der sofortige Gebrauch durch den Benutzeragent ist. Der Header hat derzeit einen möglichen Wert, prefetch, der anzeigt, dass die Ressource vorzeitig für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungsheader, der bei einer vorzeitigen Anfrage gesendet wird, um eine Ressource während des Bootens eines Service-Workers mit fetch() zu laden. Der Wert, der mit NavigationPreloadManager.setHeaderValue() festgelegt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource zurückgegeben werden soll als bei einer normalen fetch()-Operation.

Server-gesendete Ereignisse

Reporting-Endpoints: Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an denen der Browser bei der Nutzung der Reporting API Warnungen und Fehlerberichte senden soll.
Report-To Veraltet Nicht standardisiert: Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an denen der Browser bei der Nutzung der Reporting API Warnungen und Fehlerberichte senden soll.

Transferkodierung

Transfer-Encoding: Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.
TE: Gibt die Transferkodierungen an, die der Benutzeragent zu akzeptieren bereit ist.
Trailer: Ermöglicht es dem Absender, am Ende der Chunked-Nachricht zusätzliche Felder einzufügen.

WebSockets

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

Sec-WebSocket-Accept: Antwortheader, der angibt, dass der Server bereit ist, zu einer WebSocket-Verbindung zu wechseln.
Sec-WebSocket-Extensions: In Anfragen gibt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten gibt er die vom Server aus den Präferenzen des Clients ausgewählte Erweiterung an.
Sec-WebSocket-Key: Anforderungsheader, der einen Schlüssel enthält, der überprüft, dass der Client explizit die Absicht hat, eine WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die unterstützten Unterprotokolle des Clients in bevorzugter Reihenfolge an. In Antworten gibt er das vom Server aus den Präferenzen des Clients ausgewählte Unterprotokoll an.
Sec-WebSocket-Version: In Anfragen gibt 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 vom Server unterstützten Versionen auf.

Sonstige

Alt-Svc: Wird verwendet, um alternative Möglichkeiten zur Erreichung dieses Dienstes aufzulisten.
Alt-Used: Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.
Date: Enthält das Datum und die Uhrzeit, zu der die Nachricht originated wurde.
Link: Dieses Entity-Header-Feld bietet eine Möglichkeit zur Serialisierung von einem oder mehreren Links in HTTP-Headern. Es ist semantisch äquivalent zum HTML <link> Element.
Retry-After: Gibt an, wie lange der Benutzeragent warten soll, bevor er eine Folgeanfrage stellt.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.
Service-Worker-Allowed: Wird verwendet, um die Pfadeinschränkung zu entfernen, indem dieser Header in der Antwort des Service Worker Skripts enthalten ist.
SourceMap: Verlinkt auf eine Quellkarte, damit Debugger durch den ursprünglichen Quellcode anstelle von generiertem oder transformiertem Code schrittweise gehen können.
Upgrade: Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits hergestellte Client-/Serververbindung zu einem anderen Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Zum Beispiel kann es 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 eine WebSocket-Verbindung zu ändern.
Priority: Bietet einen Hinweis auf die Priorität einer bestimmten Ressourcenanforderung auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzuzeigen, oder in einer Antwort, wenn der Server entscheidet, die Anforderung neu zu priorisieren.

Experimentelle Header

Attributionsbericht-Header

Die Attribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen — beispielsweise, wenn ein Benutzer auf eine auf einer Website eingebettete Anzeige klickt und dann auf der Website des Anbieters den Artikel kauft — und dann Berichte über diese Konversionen zuzugreifen. Dies geschieht ohne die Verwendung von Drittanbieter-Tracking-Cookies, sondern indem es sich auf verschiedene Header stützt, um Quellen und Auslöser zu registrieren, die übereinstimmen, um eine Konversion anzuzeigen.

Attribution-Reporting-Eligible: Wird verwendet, um anzuzeigen, dass die Antwort, die der aktuellen Anfrage entspricht, zur Teilnahme an der Attributionsberichterstattung berechtigt ist, indem entweder eine Attributionsquelle oder ein Auslöser registriert wird.
Attribution-Reporting-Register-Source: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible Header enthielt, verwendet, um eine Attributionsquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible Header enthielt, verwendet, um einen Attribution-Auslöser zu registrieren.

Client-Hinweise

HTTP Client-Hinweise sind eine Reihe von Anforderungsheadern, die nützliche Informationen über den Client wie Gerätetyp und Netzbedingungen bereitstellen und es Servern ermöglichen, das, was für diese Bedingungen bedient wird, zu optimieren.

Server fordern proaktiv die Client-Hinweis-Header an, an denen sie interessiert sind, vom Client mit Accept-CH an. Der Client kann dann entscheiden, ob er die angeforderten Header in nachfolgenden Anfragen einbezieht.

Accept-CH: Server können Unterstützung für Client-Hinweise über das Accept-CH Header-Feld oder ein entsprechendes HTML <meta> Element mit http-equiv Attribut bekannt geben.
Critical-CH Experimentell: Server verwenden Critical-CH zusammen mit Accept-CH um anzugeben, dass akzeptierte Client-Hinweise auch kritische Client-Hinweise sind.

Die unterschiedlichen Kategorien von Client-Hinweisen sind unten aufgelistet.

Benutzeragent-Client-Hinweise

Die UA-Client-Hinweise sind Anforderungsheader, die Informationen über den Benutzeragent, die Plattform/Architektur, auf der er läuft, und Benutzereinstellungen, die im Benutzeragent oder der Plattform festgelegt sind, bereitstellen:

Sec-CH-UA Experimentell: Marken- und Versionsinformationen des Benutzeragents.
Sec-CH-UA-Arch Experimentell: Die zugrundeliegende Plattformarchitektur des Benutzeragents.
Sec-CH-UA-Bitness Experimentell: Bitanzahl der zugrundeliegenden CPU-Architektur (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factor Experimentell: Formfaktoren des Benutzeragents, die beschreiben, wie der Benutzer mit dem Benutzeragent interagiert.
Sec-CH-UA-Full-Version Veraltet: Vollständige Versionszeichenfolge des Benutzeragents.
Sec-CH-UA-Full-Version-List Experimentell: Vollversion für jede Marke in der Markenliste des Benutzeragents.
Sec-CH-UA-Mobile Experimentell: Der Benutzeragent läuft auf einem mobilen Gerät oder bevorzugt allgemein eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model Experimentell: Gerätemodell des Benutzeragents.
Sec-CH-UA-Platform Experimentell: Das zugrundeliegende Betriebssystem/Plattform des Benutzeragents.
Sec-CH-UA-Platform-Version Experimentell: Versionsnummer des zugrundeliegenden Betriebssystems des Benutzeragents.
Sec-CH-UA-WoW64 Experimentell: Ob der Benutzeragent im 32-Bit-Modus auf 64-Bit-Windows ausgeführt wird oder nicht.
Sec-CH-Prefers-Color-Scheme Experimentell: Farbthemenpräferenz des Benutzers für hell oder dunkel.
Sec-CH-Prefers-Reduced-Motion Experimentell: Vorliebe des Benutzers, weniger Animationen und Verschiebungen des Inhaltslayouts zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anforderungsheader, der die Vorliebe des Benutzeragents für reduzierte Transparenz angibt.

Hinweis: Benutzeragent-Client-Hinweise sind nicht innerhalb von fenced frames verfügbar, da sie sich auf die Berechtigungsrichtlinie verlassen, die genutzt werden könnte, um Daten zu leaken.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert: Antwortheader, der verwendet wird, um das Bildgerät zu Pixelverhältnis (DPR) in Anfragen zu bestätigen, bei denen der Client-Hinweis DPR verwendet wurde, um eine Bildressource auszuwählen.
Device-Memory: Ungefähre Menge an verfügbarem RAM-Speicher des Clients. Dies ist Teil der Device Memory API.
DPR Veraltet Nicht standardisiert: Anforderungsheader, der das Pixelverhältnis des Clientgeräts bereitstellt (die Anzahl physischer Gerätepixel für jedes CSS-Pixel).
Viewport-Width Veraltet Nicht standardisiert: Anforderungsheader, der die Breite des Layout-Viewports des Clients in CSS-Pixeln bereitstellt.
Width Veraltet Nicht standardisiert: Anforderungsheader, der die gewünschte Ressourcenbreite in physischen Pixeln angibt (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise ermöglichen einem Server, basierend auf der Benutzerwahl und der Netzwerk-Bandbreite und -Latenz zu entscheiden, welche Informationen gesendet werden.

Downlink Experimentell: Ungefähre Bandbreite der Client-Verbindung zum Server, in Mbps. 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: Anwendungsrundlaufzeit (RTT) in Millisekunden, die auch die Serververarbeitungszeit einschließt. Dies ist Teil der Network Information API.
Save-Data Experimentell: Eine Zeichenfolge on, die die Präferenz des Benutzeragents für die Reduzierung der Datennutzung angibt.

Datenschutz

DNT Veraltet Nicht standardisiert: Anforderungsheader, der die Tracking-Präferenz des Benutzers anzeigt (Do Not Track). Er ist zugunsten der Global Privacy Control (GPC) veraltet, die Server über den Sec-GPC Header informiert und Clients über navigator.globalPrivacyControl zugänglich macht.
Tk Veraltet Nicht standardisiert: Antwortheader, der den Tracking-Status angibt, der auf die entsprechende Anfrage angewendet wurde. Wird in Verbindung mit DNT verwendet.
Sec-GPC Nicht standardisiert Experimentell: Gibt an, ob der Benutzer einem Verkauf oder Teilen seiner persönlichen Informationen mit Dritten durch eine Website oder Dienst zustimmt.

Sicherheit

Origin-Isolation Experimentell: Bietet einen Mechanismus, um Webanwendungen zu ermöglichen, ihre Ursprünge zu isolieren.

Server-gesendete Ereignisse

NEL Experimentell: Definiert einen Mechanismus, der Entwicklern ermöglicht, eine Netzwerkfehlerbericht-Richtlinie zu deklarieren.

Themen-API

Die Themen-API bietet einen Mechanismus, mit dem Entwickler Anwendungsfälle wie interessenbasierte Werbung (IBA) umsetzen können. Siehe die Themen-API-Dokumentation für weitere Informationen.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwortheader, der verwendet wird, um vom antwortenden Standort abgeleitete Themen von Interesse als beobachtet im Antwort auf eine von einer Funktion, die die Themen-API ermöglicht generierte Anfrage zu markieren.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Antwortheader, 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.

Sonstige

Accept-Signature Experimentell: Ein Client kann den Accept-Signature Header senden, um die Absicht zu signalisieren, verfügbare Signaturen zu nutzen und anzugeben, welche Arten von Signaturen er unterstützt.
Early-Data Experimentell: Gibt an, dass die Anfrage in TLS-Frühdaten übertragen wurde.
Origin-Agent-Cluster Experimentell: Antwortheader, der verwendet wird, um anzuzeigen, dass das zugehörige Document in ein ursprungsbasiertes Agent-Cluster platziert werden soll. Diese Isolation ermöglicht es Benutzer-Agents, für Agent-Cluster implementationsspezifische Ressourcen, wie Prozesse oder Threads, effizienter zuzuweisen.
Set-Login Experimentell: Antwortheader, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, was bedeutet, ob irgendwelche Benutzer im aktuellen Browser beim IdP angemeldet sind oder nicht. Diese Information wird vom Browser gespeichert und vom FedCM-API verwendet.
Signature Experimentell: Der Signature Header gibt eine Liste von Signaturen für einen Austausch zusammen mit Informationen darüber an, wie die Autorität dieser Signatur bestimmt und aktualisiert werden kann.
Signed-Headers Experimentell: Der Signed-Headers Header identifiziert eine geordnete Liste von Antwortheader-Feldern, die in eine Signatur aufgenommen werden sollen.
Speculation-Rules Experimentell: Bietet eine Liste von URLs, die auf Textressourcen mit Spekulationsregel JSON-Definitionen verweisen. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregelsatz des Dokuments hinzugefügt.
Supports-Loading-Mode Experimentell: Wird von einem Navigationsziel gesetzt, um die Verwendung von verschiedenen risikoreicheren Lademodi zu ermöglichen. Zum Beispiel, das Cross-Origin, gleiche Standort Prerendering erfordert einen Supports-Loading-Mode-Wert von credentialed-prerender.

Nicht-standardisierte Header

X-Forwarded-For Nicht standardisiert: Identifiziert die ursprünglichen IP-Adressen eines Kunden, der sich über einen HTTP-Proxy oder einen Lastverteiler mit einem Webserver verbindet.
X-Forwarded-Host Nicht standardisiert: Identifiziert den ursprünglichen Host, der von einem Client verwendet wurde, um eine Verbindung zu Ihrem Proxy oder Lastverteiler herzustellen.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das von einem Client verwendet wurde, um eine Verbindung zu Ihrem Proxy oder Lastverteiler herzustellen.
X-DNS-Prefetch-Control Nicht standardisiert: Steuert DNS Prefetching, eine Funktion, bei der Browser proaktiv die Domain-Namenauflösung sowohl für Links, die der Benutzer möglicherweise folgt, als auch für URLs durchführen, die durch das Dokument referenziert werden, einschließlich Bilder, CSS, JavaScript usw.
X-Robots-Tag Nicht standardisiert: Der X-Robots-Tag HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb von öffentlichen Suchmaschinenergebnissen indexiert werden soll. Der Header ist im Wesentlichen äquivalent zu <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet: Implementierungsspezifischer Header, der an verschiedenen Stellen entlang der Anforderungs-Antwort-Kette verschiedene Effekte haben kann. Wird für die Abwärtskompatibilität mit HTTP/1.0 Caches verwendet, bei denen der Cache-Control Header noch nicht vorhanden ist.
Warning Veraltet: Allgemeine Warninformationen über mögliche Probleme.

Mitwirkung

Sie können helfen, indem Sie neue Einträge schreiben oder bestehende verbessern.