HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort auszutauschen. In HTTP/1.X ist ein Header ein nicht auf Groß-/Kleinschreibung achtender Name, gefolgt von einem Doppelpunkt, dann folgt optional ein Leerzeichen, das ignoriert wird, und schließlich sein Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header klein geschrieben, wenn sie in den Entwicklertools angezeigt 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 deprekiert, da sie bei der Standardisierung von nicht standardmäßigen Feldern Unannehmlichkeiten verursachte, wie in RFC 6648 beschrieben. Weitere sind im IANA HTTP-Feldnamen-Register aufgelistet, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status.

Header können gemäß 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: Enthalten zusätzliche Informationen über die Antwort, wie ihren Standort oder über den Server, der sie bereitstellt.
Representation-Header: Enthalten Informationen über den Inhalt der Ressource, wie ihren MIME-Typ oder Kodierung/Kompression, die angewendet wurde.
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 gruppiert werden, je nachdem, wie Proxys sie behandeln:

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. Zwischenliegende 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 Transportverbindung sinnvoll und dürfen nicht von Proxys weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mit dem Connection-Header gesetzt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden soll.
Authorization: Enthält die Anmeldedaten, um einen Benutzeragenten 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 Benutzeragenten bei einem Proxy-Server zu authentifizieren.

Zwischenspeicherung

Age: Die Zeit in Sekunden, die das Objekt im Proxy-Cache war.
Cache-Control: Anweisungen für Zwischenspeicherungsmechanismen sowohl in Anfragen als auch in 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 gilt.
No-Vary-Search Experimentell: Gibt eine Reihe von Regeln an, die bestimmen, wie sich die Abfrageparameter einer URL auf das Cache-Matching auswirken. Diese Regeln diktieren, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Bedingungen

Last-Modified: Das letzte Änderungsdatum der Ressource, das verwendet wird, um verschiedene Versionen derselben Ressource zu vergleichen. 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: Eine eindeutige Zeichenkette, die 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 (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 ü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 stellt die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen sicher oder implementiert ein optimistisches Konkurrentzkontrollsystem bei Änderungen an vorhandenen Dokumenten.
Vary: Bestimmt, wie Anforderungsheader abgeglichen werden sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.

Verbindungsmanagement

Connection: Steuert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion offen bleibt.
Keep-Alive: Steuert, wie lange eine dauerhafte Verbindung offen bleiben soll.

Inhaltsaushandlung

Für weitere Details lesen Sie den Artikel 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, in der die Antwort erwartet wird. Dies ist ein Hinweis und nicht unbedingt vollständig unter der Kontrolle des Nutzers: Der Server sollte immer darauf achten, keine explizite Benutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown-Menü) zu überschreiben.
Accept-Patch: Ein request content negotiation Response-Header, der angibt, welche Medientypen der Server in einer PATCH-Anfrage verstehen kann.
Accept-Post: Ein request content negotiation Response-Header, der angibt, welche Medientypen 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 verarbeiten.
Max-Forwards: Bei Verwendung von TRACE gibt es die maximale Anzahl von Hops an, die die Anfrage durchlaufen kann, bevor sie an den Absender zurückgesendet 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 weitere Informationen lesen Sie die CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage freigegeben werden kann, wenn das Merkmal credentials wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, 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 zwischengespeichert werden können.
Access-Control-Request-Headers: Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um den Server über die HTTP-Header zu informieren, die bei der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um den Server darüber zu informieren, welche HTTP-Methode bei der tatsächlichen Anfrage verwendet wird.
Origin: Gibt an, von wo ein Abruf stammt.
Timing-Allow-Origin: Gibt Ursprünge an, denen erlaubt ist, die Werte von Attributen zu sehen, die über Funktionen der Resource Timing API abgerufen wurden, die ansonsten aufgrund von Cross-Origin-Einschränkungen als Null gemeldet 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 gehandhabt werden soll und der Browser ein "Speichern unter"-Dialog präsentieren soll.

Integritäts-Prüfsummen

Content-Digest Experimentell: Bietet eine Prüfsumme des oktettumrahmten Streams in einer HTTP-Nachricht (der Nachrichteninhalt), abhängig von Content-Encoding und Content-Range.
Repr-Digest Experimentell: Bietet eine Prüfsumme der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zum Content-Digest berücksichtigt die Prüfsumme nicht Content-Encoding oder Content-Range.
Want-Content-Digest Experimentell: Ausdruck des Wunsches nach einem Content-Digest-Header. Es ist das Content- Analog zum Want-Repr-Digest.
Want-Repr-Digest Experimentell: Ausdruck des Wunsches nach einem Repr-Digest-Header. Es ist das Repr- Analog zum Want-Content-Digest.

Nachrichtenkörperinformationen

Content-Length: Die Größe der Ressource, in Dezimalzahlen von Bytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Wird verwendet, um den Kompressionsalgorithmus zu spezifizieren.
Content-Language: Beschreibt die menschliche Sprache(n), die für das Publikum bestimmt sind, sodass 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.

Proxys

Forwarded: Enthält Informationen von der clientseitigen Seite von Proxy-Servern, die geändert oder verloren gehen, wenn ein Proxy im Pfad der Anfrage beteiligt ist.
Via: Wird von Proxys hinzugefügt, sowohl vorwärts- als auch rückwärts-Proxys, und kann in den Anforderungsheadern und den Antwortheadern auftreten.

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 Downloadmanager, die es dem Benutzer ermöglichen, einen Download zu pausieren und fortzusetzen.

Accept-Ranges: Gibt an, ob der Server Bereichsanfragen unterstützt und in welcher Einheit der Bereich angegeben 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 angegebene ETag oder 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örper eine Teilnachricht gehört.

Weiterleitungen

Location: Gibt die URL an, zu der eine Seite umgeleitet werden soll.
Refresh: Weist den Browser an, die Seite neu zu laden oder zu einer anderen weiterzuleiten. Nimmt den gleichen Wert 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 Benutzeragenten steuert.
Host: Gibt den Domain-Namen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, an der der Server auf Anfragen lauscht.
Referer: Die Adresse der vorherigen Webseite, von der ein Link zu der aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy: Regelt, welche Referrer-Informationen im Referer-Header mit Anfragen gesendet werden sollen.
User-Agent: Enthält eine charakteristische Zeichenfolge, die es Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Software-Anbieter oder die Softwareversion des anfordernden Benutzersoftwareagenten zu identifizieren.

Antwortkontext

Allow: Listet die von einer Ressource unterstützten HTTP-Anforderungsmethoden auf.
Server: Enthält Informationen über die Software, die der Ursprungsserver verwendet, um die Anfrage zu bearbeiten.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht es einem Server, eine Einbettungsrichtlinie für ein bestimmtes Dokument zu erklären.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domains ein Fenster öffnen/steuern.
Cross-Origin-Resource-Policy (CORP): Verhindert, dass andere Domains die Antwort der Ressourcen auslesen, auf die dieser Header angewendet wird. Siehe auch CORP-Erklärungsartikel.
Content-Security-Policy (CSP): Steuert Ressourcen, die der Benutzeragent 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, aber nicht durchsetzen. Diese Verstöße bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.
Expect-CT Veraltet: Ermöglicht es Websites, sich in die Berichterstattung und Durchsetzung der Zertifikattransparenz einzutragen, um die Verwendung von fälschlicherweise ausgestellten 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 sie einbetten, zu erlauben oder zu verbieten.
Reporting-Endpoints Experimentell: Antwortheader, der Website-Besitzern erlaubt, einen oder mehrere Endpunkte anzugeben, die zum Empfang von Fehlern wie CSP-Verstoßmeldungen, Cross-Origin-Opener-Policy-Berichten oder anderen generischen Verstößen verwendet werden.
Strict-Transport-Security (HSTS): Erzwingt die Kommunikation über HTTPS anstatt 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 die upgrade-insecure-requests-Direktive erfolgreich handhaben kann.
X-Content-Type-Options: Deaktiviert das MIME-Sniffing und erzwingt, dass der Browser den in Content-Type angegebenen Typ verwendet.
X-Frame-Options (XFO): Gibt an, ob ein Browser erlaubt sein sollte, eine Seite in einem <frame>, <iframe>, <embed> oder <object> darzustellen.
X-Permitted-Cross-Domain-Policies: Eine Cross-Domain-Policy-Datei kann Clients, wie Adobe Acrobat oder Apache Flex (unter anderem), die Erlaubnis erteilen, Daten über Domains hinweg zu bearbeiten, die ansonsten aufgrund der Same-Origin-Richtlinie 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 festgelegt werden und enthält Informationen über diese, während sie keine Nützlichkeit für die Anwendung oder ihre Besucher bieten. Entfernen Sie diesen Header, um potenzielle Sicherheitslücken zu vermeiden.
X-XSS-Protection: Aktiviert das Filtern von Cross-Site-Scripting.

Fetch-Metadaten-Anforderungsheader

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

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprung des Anforderungsinitiators und dem Zielursprung an. Es ist ein struktureller 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 ist ein struktureller 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 Benutzeraktivierung ausgelöst wurde. Es ist ein struktureller Header, dessen Wert ein boolescher ist, sodass mögliche Werte ?0 für falsch und ?1 für wahr sind.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es ist ein struktureller 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", bieten jedoch ähnlich Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Cache-Verhalten oder die zurückgegebenen Informationen zu ändern:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als die unmittelbare Nutzung durch den Benutzeragenten ist. Der Header hat derzeit einen möglichen Wert, prefetch, der angibt, dass die Ressource vorzeitig für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungsheader, der in vorzeitigen Anfragen gesendet wird, um eine Ressource während des Bootens eines Service-Workers mit fetch() abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() festgelegt wird, kann verwendet werden, um einen Server zu informieren, dass eine andere Ressource als bei einem normalen fetch()-Vorgang zurückgegeben werden sollte.

Server-sent Events

Reporting-Endpoints: Antwortheader, der verwendet wird, um Server-Endpunkte anzugeben, an die der Browser beim Verwenden der Reporting-API Warnungen und Fehlermeldungen senden soll.
Report-To Veraltet Nicht standardisiert: Antwortheader, der verwendet wird, um Server-Endpunkte anzugeben, an die der Browser beim Verwenden der Reporting-API Warnungen und Fehlermeldungen senden soll.

Transfer-Codierung

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

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 umzusteigen.
Sec-WebSocket-Extensions: In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten WebSocket-Erweiterungen an. In Antworten zeigt er die vom Server aus den Präferenzen des Clients ausgewählten Erweiterungen an.
Sec-WebSocket-Key: Anforderungsheader, der einen Schlüssel enthält, der bestätigt, dass der Client ausdrücklich beabsichtigt, einen WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten Subprotokolle an. In Antworten zeigt er das vom Server aus den Präferenzen des Clients ausgewählte Subprotokoll 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 nicht vom Server unterstützt wird, und listet die vom Server unterstützten Versionen auf.

Andere

Alt-Svc: Wird verwendet, um alternative Wege aufzulisten, diesen Dienst zu erreichen.
Alt-Used: Wird verwendet, um den alternativen Dienst zu identifizieren, der verwendet wird.
Date: Enthält das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde.
Link: Dieses Entity-Header-Feld bietet eine Möglichkeit zur Serialisierung eines oder mehrerer Links in HTTP-Headern. Es ist semantisch äquivalent zum HTML-<link>-Element.
Retry-After: Gibt an, wie lange der Benutzeragent warten sollte, bevor er eine Folgeanfrage stellt.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.
Service-Worker: Wird in Abrufe für die Skriptressource eines Service-Workers einbezogen. Dieser Header hilft Administratoren, Service-Worker-Skriptanfragen zu Überwachungszwecken zu protokollieren.
Service-Worker-Allowed: Wird verwendet, um die Pfadbeschränkung durch Hinzufügen dieses Headers in der Antwort des Service-Worker-Skripts zu entfernen.
SourceMap: Verlinkt zu einer Source-Map, damit Debugger durch den ursprünglichen Quellcode anstelle von generiertem oder transformiertem Code schrittweise vorgehen können.
Upgrade: Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Zum Beispiel kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 zu aktualisieren oder eine HTTP- oder HTTPS-Verbindung auf einen WebSocket umzustellen.
Priority: Bietet 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 anzugeben, oder in einer Antwort, wenn der Server die Neupriorisierung der Anfrage wählt.

Experimentelle Header

Zuordnungsberichterstattung Header

Die Attribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen — zum Beispiel, wenn ein Benutzer auf eine Anzeige klickt, die auf einer Site eingebunden ist, und dann auf der Website des Verkäufers einen Kauf tätigt — und dann Berichte über diese Konversionen zuzugreifen. Dies erfolgt ohne Verlassen auf Cookies von Drittanbietern, sondern durch verschiedene Header zur Registrierung von Quellen und Auslösern, die zusammenpassen, um eine Konversion anzuzeigen.

Attribution-Reporting-Eligible: Wird verwendet, um anzugeben, dass die Antwort zur aktuellen Anfrage berechtigt ist, an der Zuordnungsberichterstattung teilzunehmen, indem entweder eine Zuordnungsquelle oder ein Auslöser registriert wird.
Attribution-Reporting-Register-Source: Wird als Teil einer Antwort auf eine Anfrage hinzugefügt, die einen Attribution-Reporting-Eligible-Header enthielt, um eine Zuordnungsquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Wird als Teil einer Antwort auf eine Anfrage hinzugefügt, die einen Attribution-Reporting-Eligible-Header enthielt, um einen Zuordnungsauslöser zu registrieren.

Client-Hinweise

HTTP-Client-Hinweise sind eine Reihe von Anfrage-Headern, die nützliche Informationen über den Client wie Gerätetyp und Netzwerkbedingungen bieten und es Servern ermöglichen, das zu optimieren, was unter diesen Bedingungen bereitgestellt wird.

Server fordern proaktiv die Client-Hinweise an, an denen sie vom Client interessiert sind, indem sie Accept-CH verwenden. Der Client kann dann wählen, die angeforderten Header in nachfolgenden Anfragen einzubeziehen.

Accept-CH: Server können Unterstützung für Client-Hinweise mithilfe des Accept-CH-Header-Felds oder eines äquivalenten HTML-<meta>-Elements mit http-equiv Attribut ankündigen.
Critical-CH Experimentell: Server verwenden Critical-CH zusammen mit Accept-CH, um anzumelden, dass akzeptierte Client-Hinweise auch kritische Client-Hinweise sind.

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

Benutzeragenten-Client-Hinweise

Die UA-Client-Hinweise sind Anfrage-Header, die Informationen über den Benutzeragenten, die Plattform/Architektur, auf der er läuft, und die Benutzereinstellungen liefern, die im Benutzeragenten oder auf der Plattform festgelegt sind:

Sec-CH-UA Experimentell: Benutzeragenten-Branding und Version.
Sec-CH-UA-Arch Experimentell: Unterliegende Plattform-Architektur des Benutzeragenten.
Sec-CH-UA-Bitness Experimentell: Unterliegende CPU-Architektur-Bitness des Benutzeragenten (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factor Experimentell: Formfaktoren des Benutzeragenten, die beschreiben, wie der Benutzer mit dem Benutzeragenten interagiert.
Sec-CH-UA-Full-Version Veraltet: Vollständige Versionszeichenfolge 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 allgemein eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model Experimentell: Gerätemodell des Benutzeragenten.
Sec-CH-UA-Platform Experimentell: Unterliegendes Betriebssystem/Plattform des Benutzeragenten.
Sec-CH-UA-Platform-Version Experimentell: Version des unterliegenden Betriebssystems des Benutzeragenten.
Sec-CH-UA-WoW64 Experimentell: Ob der Benutzeragenten-Binärcode im 32-Bit-Modus unter 64-Bit-Windows läuft.
Sec-CH-Prefers-Color-Scheme Experimentell: Vorliebe des Nutzers für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion Experimentell: Vorliebe des Nutzers, weniger Animationen und Inhaltslayoutveränderungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anfrage-Header gibt die Präferenz des Benutzeragenten für reduzierte Transparenz an.

Hinweis: Benutzeragenten-Client-Hinweise sind nicht innerhalb von fenced frames verfügbar, weil sie auf die Delegation der Berechtigungsrichtlinie angewiesen sind, die zur Datenweitergabe genutzt werden könnte.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert: Antwortheader, der verwendet wird, um das Bildgerät zum Pixel-Verhältnis (DPR) in Anfragen zu bestätigen, 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: Anfrage-Header, der das Pixelverhältnis des Client-Geräts angibt (die Anzahl physischer Gerätepixel pro CSS-Pixel).
Viewport-Width Veraltet Nicht standardisiert: Anfrage-Header gibt die Layout-Viewport-Breite des Clients in CSS-Pixeln an.
Width Veraltet Nicht standardisiert: Anfrage-Header gibt die gewünschte Ressourcenbreite in physikalischen Pixeln an (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise ermöglichen es einem Server, zu wählen, welche Informationen gesendet werden, basierend auf den Benutzerentscheidungen und Netzwerkbandbreite und -latenz.

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 am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.
RTT Experimentell: Anwendungsschicht-Round-Trip-Time (RTT) in Millisekunden, die die Serververarbeitungszeit einschließt. Dies ist Teil der Network Information API.
Save-Data Experimentell: Ein Zeichenfolgenwert on, der die Vorliebe des Benutzeragenten für reduzierte Datennutzung angibt.

Privatsphäre

DNT Veraltet Nicht standardisiert: Anfrage-Header, der die Vorliebe des Benutzers bezüglich Tracking (Do Not Track) angibt. Nicht mehr empfohlen zugunsten von Global Privacy Control (GPC), das den Servern mit dem Sec-GPC-Header mitgeteilt wird und den Clients über navigator.globalPrivacyControl zugänglich ist.
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 zustimmt, dass eine Website oder Dienstleistung ihre persönlichen Informationen mit Dritten verkauft oder teilt.

Sicherheit

Origin-Agent-Cluster Experimentell: Antwortheader, der verwendet wird, um anzugeben, dass das zugehörige Dokument in einem ursprungsschlüssel-Agentencluster platziert werden soll. Diese Isolierung ermöglicht es Benutzeragenten, implementationsspezifische Ressourcen für Agentencluster, wie Prozesse oder Threads, effizienter zuzuweisen.

Server-sent Events

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

Topics-API

Die Topics-API bietet Entwicklern einen Mechanismus zur Implementierung von Anwendungsfällen wie interessenbasierte Werbung (IBA). Siehe die Topics-API-Dokumentation für weitere Informationen.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwortheader, der verwendet wird, um Themen von Interesse zu kennzeichnen, die aus der URL einer aufrufenden Site als in der Antwort auf eine Anfrage beobachtet markiert wurden, die von einer Funktion, die die Topics-API ermöglicht, generiert wurde.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Anfrage-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Werbungstechnologie-Plattform verwendet werden, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.

Andere

Accept-Signature Experimentell: Ein Client kann den ACCEPT-Signature-Header senden, um die Absicht anzuzeigen, etwaige verfügbare Signaturen zu nutzen, und um anzugeben, welche Arten 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 festzulegen, d.h., ob Benutzer im aktuellen Browser beim IdP eingeloggt 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 bestimmt und die Signatur aktualisiert werden kann.
Signed-Headers Experimentell: Das Signed-Headers-Header-Feld identifiziert eine geordnete Liste von Antwortheadern, die in eine Signatur aufgenommen werden sollen.
Speculation-Rules Experimentell: Bietet eine Liste von URLs, die zu Textressourcen zeigen, die Spekulationsregeln-JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zur Spekulationsregelsatz des Dokuments hinzugefügt.
Supports-Loading-Mode Experimentell: Setzt ein Navigationsziel, um sich für die Verwendung verschiedener risikoreicheren Lademodi zu entscheiden. Zum Beispiel erfordert das präfektierte, gleiche-Site (domänenübergreifende) Vorladen 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 über einen HTTP-Proxy oder einen Lastenausgleich zu einem Webserver Verbindungen herstellt.
X-Forwarded-Host Nicht standardisiert: Identifiziert den ursprünglichen Host, den ein Client verwendet, um eine Verbindung zu Ihrem Proxy oder Lastenausgleich herzustellen.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet, um eine Verbindung zu Ihrem Proxy oder Lastenausgleich herzustellen.
X-DNS-Prefetch-Control Nicht standardisiert: Steuert das DNS-Vorabrufen, eine Funktion, bei der Browser proaktiv die Domainnamensauflösung sowohl auf Links, die der Benutzer möglicherweise auswählt, als auch auf URLs für Elemente, die vom Dokument referenziert werden, einschließlich Bildern, CSS, JavaScript usw., durchführen.
X-Robots-Tag Nicht standardisiert: Der X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite in den öffentlichen Suchmaschinenergebnissen indiziert werden soll. Der Header ist im Grunde äquivalent zu <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet: Implementationsspezifischer Header, der entlang der gesamten Anforderungs-/Antwortkette verschiedene Auswirkungen haben kann. Wird zur 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.

Beitrag leisten

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