HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort zu senden. In HTTP/1.X besteht ein Header aus einem nicht case-sensitiven Namen, gefolgt von einem Doppelpunkt, optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header kleingeschrieben angezeigt, wenn sie in Entwicklertools betrachtet werden (accept: */*) und mit einem Doppelpunkt für eine spezielle Gruppe von Pseudo-Headern 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 auftraten, wenn nicht standardmäßige Felder standardisiert wurden, in RFC 6648 abgeschafft; andere sind im IANA HTTP Field Name Registry aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert war. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status.

Header können je nach ihrem Kontext gruppiert werden:

Anfrage-Header: Enthalten weitere Informationen über die anzufordernde Ressource oder über den Client, der die Ressource anfordert.
Antwort-Header: Halten zusätzliche Informationen über die Antwort, wie ihren Standort oder über den Server, der sie bereitstellt.
Darstellungs-Header: Enthalten Informationen über den Hauptteil der Ressource, wie ihren MIME-Typ oder die angewendete Kodierung/Kompression.
Nutzdaten-Header: Enthalten darstellungsunabhängige Informationen über Nutzdaten, einschließlich Inhaltlänge und der für den Transport verwendeten Kodierung.

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

End-to-End-Header: Diese Header müssen an den endgültigen Empfänger der Nachricht übermittelt werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenproxies 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 Transportverbindung sinnvoll und dürfen nicht von Proxies weiterübertragen oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mithilfe des Connection-Headers eingestellt werden können.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die zur Zugriffsberechtigung auf eine Ressource verwendet werden soll.
Authorization: Enthält die Anmeldedaten, um einen User-Agent bei einem Server zu authentifizieren.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden soll.
Proxy-Authorization: Enthält die Anmeldedaten, um einen User-Agent bei einem Proxy-Server zu authentifizieren.

Zwischenspeicherung

Age: Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache gewesen ist.
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 der anfordernden Website zugeordnet 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-Matching beeinflussen. Diese Regeln bestimmen, ob die gleiche URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Bedingungen

Last-Modified: Das Datum der letzten Änderung der Ressource, verwendet, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau als ETag, aber einfacher in manchen Umgebungen 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 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 vorhanden ist.
If-Modified-Since: Macht die Anfrage bedingt und erwartet, dass die Ressource nur dann ü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 dann übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies gewährleistet die Kohärenz eines neuen Abschnitts eines spezifischen Bereichs mit vorherigen oder um ein optimistisches Parallelitätskontrollsystem bei der Änderung bestehender Dokumente umzusetzen.
Vary: Bestimmt, wie Anforderungs-Header übereinstimmen sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.

Verbindungsmanagement

Connection: Kontrolliert, ob die Netzwerkverbindung offen bleibt, nachdem die aktuelle Transaktion abgeschlossen ist.
Keep-Alive: Kontrolliert, wie lange eine persistente Verbindung geöffnet bleiben soll.

Inhaltsaushandlung

Für weitere Informationen siehe den Artikel zur Inhaltsaushandlung.

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 vom Server zurückgesendet werden soll. Dies ist ein Hinweis und liegt nicht unbedingt vollständig unter der Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerwahl nicht zu überschreiben (wie die Auswahl einer Sprache aus einem Dropdown-Menü).
Accept-Patch: Ein Anfrage-Inhaltsaushandlung-Antwortheader, der anzeigt, welche Medientypen der Server in einer PATCH-Anfrage verstehen kann.
Accept-Post: Ein Anfrage-Inhaltsaushandlung-Antwortheader, der anzeigt, welche Medientypen der Server in einer POST-Anfrage verstehen kann.

Steuerungen

Expect: Zeigt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.
Max-Forwards: Gibt bei Verwendung von TRACE die maximale Anzahl von Hops an, die die Anfrage machen kann, bevor sie zum 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 User-Agent.

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 die Anmeldeflagge wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzuzeigen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden können.
Access-Control-Allow-Methods: Gibt die Methoden an, die beim Zugriff auf die Ressource als Antwort 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 gespeichert werden können.
Access-Control-Request-Headers: Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird verwendet, wenn eine Preflight-Anfrage erstellt wird, um dem Server mitzuteilen, welche HTTP-Methode bei der tatsächlichen Anfrage verwendet wird.
Origin: Gibt an, von wo eine Übertragung ausgeht.
Timing-Allow-Origin: Gibt Ursprünge an, die berechtigt sind, Werte von Attributen zu sehen, die über Funktionen der Resource Timing API abgerufen werden, die andernfalls aufgrund von Beschränkungen bei der Ursprungsübergreifung als null gemeldet werden würden.

Downloads

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

Integritäts-Hashes

Content-Digest Experimentell: Stellt einen Hash des im Http-Nachrichtenrumpf umrahmten Oktettstroms (dem Nachrichteninhalt) abhängig von Content-Encoding und Content-Range bereit.
Repr-Digest Experimentell: Stellt einen Hash der ausgewählten Repräsentation der Zielressource vor der Übertragung bereit. Im Gegensatz zum Content-Digest berücksichtigt der Hash ikke Content-Encoding oder Content-Range.
Want-Content-Digest Experimentell: Gibt den Wunsch nach einem Content-Digest Header an. Es ist das Content- Analoge zu Want-Repr-Digest.
Want-Repr-Digest Experimentell: Gibt den Wunsch nach einem Repr-Digest Header an. Es ist das Repr- Analoge zu Want-Content-Digest.

Nachrichtenteilkörper-Informationen

Content-Length: Die Größe der Ressource in Dezimalzahl der Bytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Wird verwendet, um den Kompressionsalgorithmus anzugeben.
Content-Language: Beschreibt die menschliche Sprache(n), die für das Publikum bestimmt sind, so dass es einem Benutzer ermöglicht, je nach der bevorzugten Sprache zu unterscheiden.
Content-Location: Gibt einen alternativen Ort für die zurückgegebenen Daten an.

Proxies

Forwarded: Enthält Informationen von der dem Client zugewandten Seite der Proxy-Server, die verändert oder verloren gehen, wenn ein Proxy im Pfad der Anfrage beteiligt ist.
Via: Hinzugefügt von Proxies, sowohl Vorwärts- als auch Rückwärts-Proxies, und kann in Anfrage-Headern und Antwort-Headern auftreten.

Bereichsanfragen

HTTP Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Media Player, die zufälligen Zugriff unterstützen, Datentools, 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 in welcher Einheit der Bereich ausgedrückt werden kann.
Range: Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.
If-Range: Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn das gegebene Etag oder Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen aus einer inkompatiblen Version der Ressource zu verhindern.
Content-Range: Gibt an, wo in einer vollständigen Nachricht ein Teil einer Nachricht gehört.

Umleitungen

Location: Gibt die URL an, zu der eine Seite umgeleitet werden soll.
Refresh: Weist den Browser an, die Seite neu zu laden oder an eine andere 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 User-Agent steuert.
Host: Gibt den Domainnamen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server hört.
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 sollen.
User-Agent: Enthält eine charakteristische Zeichenfolge, die es den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfordernden Software-User-Agents zu identifizieren.

Antwortkontext

Allow: Listet die Menge der HTTP-Anfragemethoden auf, die von einer Ressource unterstützt werden.
Server: Enthält Informationen über die vom Ursprungsserver verwendete Software, um die Anfrage zu bearbeiten.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht einem Server, eine Einbettungspolitik für ein gegebenes Dokument zu deklarieren.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domains ein Fenster öffnen/steuern können.
Cross-Origin-Resource-Policy (CORP): Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch CORP-Erklärerartikel.
Content-Security-Policy (CSP): Steuert, welche Ressourcen der User-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Erlaubt Webentwicklern, mit Richtlinien zu experimentieren, indem die Auswirkungen überwacht, aber nicht erzwungen werden. Diese Verstoßberichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.
Expect-CT Veraltet: Ermöglicht es Seiten, sich für die Berichterstattung und Durchsetzung von Zertifikatstransparenz zu entscheiden, um die Verwendung von falsch ausgestellten Zertifikaten für diese Seite zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Verwendung von Browserfunktionen in einem eigenen Rahmen der Website zuzulassen und zu verweigern, sowie in <iframe>s, die eingebettet sind.
Reporting-Endpoints Experimentell: Antwortheader, der es Websitebesitzern erlaubt, einen oder mehrere Endpunkte anzugeben, die verwendet werden sollen, um Fehler wie CSP-Verstoßberichte, Cross-Origin-Opener-Policy-Berichte oder andere allgemeine Verstöße zu erhalten.
Strict-Transport-Security (HSTS): Erzwingen der 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 ausdrückt und dass er erfolgreich die upgrade-insecure-requests-Direktive behandeln kann.
X-Content-Type-Options: Deaktiviert das MIME-Sniffing und zwingt den Browser, den im Content-Type-Header 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-Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domains hinweg zu verarbeiten, die sonst aufgrund der Same-Origin-Policy eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients weiterhin unerwünschte Anfragen blockieren.
X-Powered-By: Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, während sie jedoch keinen Nutzen für die Anwendung oder deren Besucher bietet. Entfernen Sie diesen Header, um potenzielle Schwachstellen nicht offenzulegen.
X-XSS-Protection: Aktiviert das Cross-Site-Scripting-Filtering.

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 erlaubt werden soll, basierend darauf, woher die Anfrage kommt und wie die Ressource verwendet wird.

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprungsort eines Anforderungsinitiators und dem Ursprungsort seines Ziels an. Es ist ein strukturierter Header, dessen Wert ein Token mit den 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 ist ein strukturierter Header, dessen Wert ein Token mit den möglichen Werten cors, navigate, no-cors, same-origin und websocket ist.
Sec-Fetch-User: Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktivierung ausgelöst wurde oder nicht. Es ist ein strukturierter Header, dessen Wert ein boolescher Wert ist, daher sind die möglichen Werte ?0 für falsch und ?1 für wahr.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es ist ein strukturierter Header, dessen Wert ein Token mit den 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 strikt "Fetch-Metadaten-Anforderungsheader", liefern jedoch ähnlich Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten zu ändern oder die zurückgegebenen Informationen:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als die unmittelbare Nutzung durch den User-Agent ist. Der Header hat derzeit einen möglichen Wert, prefetch, der anzeigt, dass die Ressource zur Vorbereitung einer möglichen zukünftigen Navigation vorab abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungsheader, der in einer vorzeitigen Anfrage gesendet wird, um fetch() eine Ressource während des Dienst-Worker-Boots abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() festgelegt wird, kann verwendet werden, um einen Server zu informieren, dass eine andere Ressource zurückgegeben werden soll als in einem normalen fetch()-Vorgang.

Server-sent events

Reporting-Endpoints: Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an denen der Browser Warn- und Fehlermeldungen beim Verwenden der Reporting API senden soll.
Report-To Veraltet Nicht standardisiert: Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an denen der Browser Warn- und Fehlermeldungen beim Verwenden der Reporting API 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 User-Agent bereit ist anzunehmen.
Trailer: Erlaubt es dem Absender, zusätzliche Felder am Ende einer gestückelten Nachricht einzuschließen.

WebSockets

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

Sec-WebSocket-Accept: Antwortheader, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung zu wechseln.
Sec-WebSocket-Extensions: In Anfragen zeigt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten zeigt 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 ausdrücklich beabsichtigt, einen WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen zeigt dieser Header die vom Client unterstützten Subprotokolle in bevorzugter Reihenfolge an. In Antworten zeigt er das vom Server aus den Präferenzen 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 vom Server unterstützten Versionen auf.

Andere

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 erstellt wurde.
Link: Dieses Entität-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 User-Agent warten soll, bevor eine Folgeanfrage gestellt wird.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den angegebenen Anfrage-Antwort-Zyklus.
Service-Worker: Wird bei Abrufen für die Ressource eines Service Workers eingeschlossen. Diese Header hilft Administratoren, Anfragen für das Service-Worker-Skript zu protokollieren, um Überwachungszwecke zu erfüllen.
Service-Worker-Allowed: Wird verwendet, um die Pfadbeschränkung durch das Einschließen dieses Headers in der Antwort des Service Worker-Skripts zu entfernen.
SourceMap: Verknüpft mit einer Source Map, damit Debugger durch ursprünglich geschriebenen Quellcode anstelle von generiertem oder transformiertem Code gehen können.
Upgrade: Dieser HTTP/1.1 (nur)-Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung auf ein anderes Protokoll (über das gleiche Transportprotokoll) zu aktualisieren. Zum Beispiel kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 zu HTTP 2.0 zu aktualisieren oder eine HTTP- oder HTTPS-Verbindung in ein WebSocket.
Priority: Liefert einen Hinweis auf die Priorität einer bestimmten Ressourcenanfrage 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 Anfrage neu zu priorisieren.

Experimentelle Header

Attributbericht-Header

Die Attributberichts-API ermöglicht es Entwicklern, Konversionen zu messen — zum Beispiel, wenn ein Benutzer auf eine auf einer Seite eingebettete Anzeige klickt und dann auf der Seite des Anbieters den Artikel kauft — und dann Berichte über diese Konversionen zu erhalten. Dies geschieht ohne den Rückgriff auf Drittanbieter-Tracking-Cookies, sondern indem auf verschiedene Header zurückgegriffen wird, um die Quellen und Auslöser zu registrieren, die zusammen eine Konvertierung angeben.

Attribution-Reporting-Eligible: Wird verwendet, um anzuzeigen, dass die Antwort auf die aktuelle Anfrage berechtigt ist, an der Attributberichterstattung teilzunehmen, indem entweder eine Attributquelle 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 Attributquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, verwendet, um einen Attributauslöser zu registrieren.

Client-Hints

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

Server fordern proaktiv die Client-Hint-Header an, die sie vom Client interessiert sind, indem sie Accept-CH verwenden. Der Client kann sich dann entscheiden, die angeforderten Header in nachfolgenden Anfragen einzuschließen.

Accept-CH: Server können Unterstützung für Client Hints mithilfe des Accept-CH-Headers oder eines äquivalenten HTML-<meta>-Elements mit http-equiv-Attributs anzeigen.
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.

Benutzeragentur-Client-Hints

Die UA-Client-Hints sind Anforderungs-Header, die Informationen über die Benutzeragentur, die Plattform/Architektur, auf der sie läuft, und Benutzereinstellungen, die in der Benutzeragentur oder Plattform gesetzt sind, bereitstellen:

Sec-CH-UA Experimentell: Marken- und Versionsinformationen der Benutzeragentur.
Sec-CH-UA-Arch Experimentell: Plattformarchitektur der Benutzeragentur.
Sec-CH-UA-Bitness Experimentell: Bitbreite der zugrunde liegenden CPU-Architektur der Benutzeragentur (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factors Experimentell: Formfaktoren der Benutzeragentur, die beschreiben, wie der Benutzer mit der Benutzeragentur interagiert.
Sec-CH-UA-Full-Version Veraltet: Vollständige Versionszeichenkette der Benutzeragentur.
Sec-CH-UA-Full-Version-List Experimentell: Vollständige Version für jede Marke in der Markenliste der Benutzeragentur.
Sec-CH-UA-Mobile Experimentell: Benutzeragentur läuft auf einem mobilen Gerät oder bevorzugt allgemein eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model Experimentell: Gerätemodell der Benutzeragentur.
Sec-CH-UA-Platform Experimentell: Betriebssystem/-plattform der Benutzeragentur.
Sec-CH-UA-Platform-Version Experimentell: Betriebssystem-Version der Benutzeragentur.
Sec-CH-UA-WoW64 Experimentell: Ob die Binärdatei der Benutzeragentur im 32-Bit-Modus auf 64-Bit-Windows läuft.
Sec-CH-Prefers-Color-Scheme Experimentell: Präferenz des Benutzers für dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion Experimentell: Präferenz des Benutzers, weniger Animationen und Inhaltslayoutverschiebungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anforderungs-Header gibt die Präferenz der Benutzeragentur für reduzierte Transparenz an.

Hinweis: Benutzer-Agent-Client-Hints stehen in verschachtelten Rahmen nicht zur Verfügung, da sie auf Berechtigungsrichtliniendelegation beruhen, die verwendet werden könnte, um Daten zu leaken.

Geräte-Client-Hints

Content-DPR Veraltet Nicht standardisiert: Antwortheader zur Bestätigung des Bildgeräte-zu-Pixel-Verhältnisses (DPR) in Anfragen, bei denen der Bildschirm-DPR-Client-Hinweis 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 Gerät-Pixel-Verhältnis des Clients angibt (die Anzahl der physischen Gerätepixel für jedes CSS-Pixel).
Viewport-Width Veraltet Nicht standardisiert: Anforderungs-Header bietet die Layout-Viewport-Breite des Clients in CSS-Pixel.
Width Veraltet Nicht standardisiert: Anforderungs-Header gibt die gewünschte Ressourcenbreite in physischen Pixeln an (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hints

Netzwerk-Client-Hints ermöglichen es einem Server, auszuwählen, welche Informationen basierend auf der Auswahl des Benutzers und der Netzwerk-Bandbreite und Latenz gesendet werden.

Downlink Experimentell: Ungefähre Bandbreite der Verbindung des Clients zum Server, in Mbit/s. Dies ist Teil der Network Information API.
ECT Experimentell: Der effektive Verbindungstyp ("Netzwerkprofil"), das Latenz und Bandbreite der Verbindung am besten entspricht. Dies ist Teil der Network Information API.
RTT Experimentell: Anwendungs-Ebene Round Trip Time (RTT) in Millisekunden, welches auch die Serververarbeitungszeit umfasst. Dies ist Teil der Network Information API.
Save-Data Experimentell: Eine Zeichenfolge on, die die Datenverbrauchspräferenz der Benutzeragentur anzeigt.

Datenschutz

DNT Veraltet Nicht standardisiert: Anforderungs-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Abgelöst durch Global Privacy Control (GPC), das den Servern über den Sec-GPC-Header mitgeteilt wird und für Clients über navigator.globalPrivacyControl zugänglich ist.
Tk Veraltet Nicht standardisiert: Antwortheader, der den Trackingstatus angibt, der auf die entsprechende Anfrage angewendet wurde. Wird in Verbindung mit DNT verwendet.
Sec-GPC Nicht standardisiert Experimentell: Gibt an, ob der Benutzer zustimmt, dass eine Website oder ein Dienst ihre persönlichen Informationen an Dritte verkauft oder teilt.

Sicherheit

Origin-Agent-Cluster Experimentell: Antwortheader, der verwendet wird, um anzuzeigen, dass das zugehörige Document in einem ursprungsbezogenen Agent-Cluster platziert werden sollte. Diese Isolation ermöglicht es Benutzeragenten, Implementierungsspezifische Ressourcen für Agent-Cluster, wie Prozesse oder Threads, effizienter zuzuweisen.

Server-sent events

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

Topics API

Die Topics-API bietet einen Mechanismus für Entwickler, um Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. Weitere Informationen finden Sie in der Topics-API-Dokumentation.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwortheader, der verwendet wird, um Themen von Interesse zu kennzeichnen, die aus der URL einer aufrufenden Site abgeleitet werden und als in der Antwort auf eine Anfrage im Rahmen eines Features, das die Topics API aktiviert, beobachtet werden.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Anforderungs-Header, der die für den aktuellen Benutzer ausgewählten Themen zusammen mit der zugehörigen Anfrage sendet, die von einer Adtech-Plattform verwendet werden, um eine personalisierte Werbung auszuwählen, die angezeigt werden soll.

Andere

Accept-Signature Experimentell: Ein Client kann den Accept-Signature-Header senden, um die Absicht anzuzeigen, von verfügbaren Signaturen zu profitieren, und um anzugeben, welche Art von Signaturen er unterstützt.
Early-Data Experimentell: Gibt an, dass die Anfrage in TLS-Frühdaten übermittelt wurde.
Set-Login Experimentell: Antwortheader, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus einzurichten, was bedeutet, ob Benutzer im aktuellen Browser beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM-API verwendet.
Signature Experimentell: Der Signature-Header-Feld überträgt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität dieser Signatur bestimmt und erneuert wird.
Signed-Headers Experimentell: Der Signed-Headers-Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur einbezogen werden sollen.
Speculation-Rules Experimentell: Bietet eine Liste von URLs, die auf Textressourcen mit Spekulationsregel-JSON-Definitionen zeigen. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregelset des Dokuments hinzugefügt.
Supports-Loading-Mode Experimentell: Vom Navigationstarget gesetzt, um die Verwendung verschiedener riskanterer Lademodi zu bestätigen. Zum Beispiel erfordert co-origins, gleich-Site prerendering 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 Lastenausgleicher mit einem Webserver verbindet.
X-Forwarded-Host Nicht standardisiert: Identifiziert den ursprünglichen Host, der von einem Client verwendet wurde, um sich mit Ihrem Proxy oder Lastenausgleicher zu verbinden.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um sich mit Ihrem Proxy oder Lastenausgleicher zu verbinden.
X-DNS-Prefetch-Control Nicht standardisiert: Steuert das DNS-Prefetching, eine Funktion, durch die Browser proaktiv die Namensauflösung für sowohl Links, die der Benutzer möglicherweise auswählt, als auch URLs für Elemente, die vom Dokument referenziert werden, einschließlich Bilder, CSS, JavaScript usw., durchführen.
X-Robots-Tag Nicht standardisiert: Der X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb öffentlicher Suchmaschinenergebnisse indexiert werden soll. Der Header ist effektiv äquivalent zu <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet: Implementierungsspezifischer Header, der überall entlang der Anforderungs-Antwort-Kette verschiedene Effekte haben kann. Wird zur Abwä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.

Mitwirken

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