HTTP-Header
HTTP-Headers ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer HTTP-Anfrage oder -Antwort zu übermitteln. Ein HTTP-Header besteht aus seinem nicht groß- und kleinschreibungsempfindlichen Namen, gefolgt von einem Doppelpunkt (:
) und dann 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 standardisiert wurden, in RFC 6648 abgeschafft. Andere sind im IANA HTTP Field Name Registry aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status, der "permanent" (standardsdefiniert), "vorläufig" (neu), "veraltet" (Nutzung nicht empfohlen) oder "obsolet" (nicht mehr in Verwendung) sein kann.
Header können nach ihren Kontexten gruppiert werden:
- Request-Headers
-
Enthalten zusätzliche Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.
- Response-Headers
-
Enthalten zusätzliche Informationen über die Antwort, wie ihren Standort oder über den Server, der sie bereitstellt.
- Representation-Headers
-
Enthalten Informationen über den Körper der Ressource, wie ihren MIME-Typ oder die angewendete Kodierung/Kompression.
- Payload-Headers
-
Enthalten darstellungsunabhängige Informationen über Nutzdaten, einschließlich deren Inhaltlänge und der für den Transport verwendeten Kodierung.
Header können auch danach gruppiert werden, wie Proxys sie behandeln:
- End-to-end-Header
-
Diese Header müssen an den Endempfänger der Nachricht übertragen werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischengeschaltete Proxys müssen diese Header unverändert weiterleiten und Caches müssen sie speichern.
- Hop-by-hop-Header
-
Diese Header sind nur für eine einzelne Transportebene Verbindung bedeutungsvoll und dürfen nicht von Proxys weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mithilfe des
Connection
Headers gesetzt werden dürfen.
Authentifizierung
WWW-Authenticate
-
Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden sollte.
-
Enthält die Anmeldedaten, um einen Benutzer-Agent bei einem Server zu authentifizieren.
Proxy-Authenticate
-
Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden sollte.
-
Enthält die Anmeldedaten, um einen Benutzer-Agent bei einem Proxy-Server zu authentifizieren.
Caching
Age
-
Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache war.
Cache-Control
-
Direktiven für Cache-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/Uhrzeit, nach dem die Antwort als veraltet angesehen 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 dieselbe URL mit unterschiedlichen URL-Parametern als separate Einträge im Browser-Cache gespeichert werden soll.
Bedingte Anfragen
Last-Modified
-
Das letzte Änderungsdatum der Ressource, verwendet, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau als
ETag
, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anfragen mitIf-Modified-Since
undIf-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
undIf-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 (für sichere Anfragen) zu aktualisieren oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine vorhanden ist.
If-Modified-Since
-
Macht die Anfrage bedingt und erwartet die Übermittlung der Ressource nur, 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 die Übermittlung der Ressource nur, 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 Konkurrenzkontrollsystem, wenn vorhandene Dokumente geändert werden.
Vary
-
Bestimmt, wie Anforderungs-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprung-Server anzufordern.
Verbindungsverwaltung
Connection
-
Steuerung, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion offen bleibt.
Keep-Alive
-
Steuerung, wie lange eine persistente Verbindung offen bleiben soll.
Inhaltsverhandlung
Für weitere Details, lesen Sie den Artikel zur Inhaltsverhandlung.
Accept
-
Informiert den Server über die Typen von Daten, die zurückgesendet werden können.
Accept-Charset
Veraltet-
Gibt die vom Client unterstützten Zeichenkodierungen an. Er ist veraltet, da UTF-8 allgegenwärtig geworden ist und die Verwendung des Headers das Fingerprinting von Clients erleichtert.
Accept-Encoding
-
Der Kodierungsalgorithmus, üblicherweise ein Kompressionsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.
Accept-Language
-
Informiert den Server über die menschliche Sprache, die der Server zurücksenden soll. Dies ist ein Hinweis und liegt nicht unbedingt vollständig unter der Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.
Accept-Patch
-
Ein Antwort-Header zur Inhaltsverhandlung von Anfragen, der anzeigt, welchen Medientyp der Server in einer
PATCH
-Anfrage verstehen kann. Accept-Post
-
Ein Antwort-Header zur Inhaltsverhandlung von Anfragen, der anzeigt, welchen Medientyp der Server in einer
POST
-Anfrage verstehen kann.
Steuerungselemente
Expect
-
Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.
Max-Forwards
-
Wenn Sie
TRACE
verwenden, gibt die maximale Anzahl von Hops an, die die Anfrage ausführen kann, bevor sie an den Absender zurückgespiegelt wird.
Cookies
-
Enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem
Set-Cookie
Header gesendet wurden. -
Sendet Cookies vom Server an den Benutzer-Agent.
CORS
Für weitere Informationen, beziehen Sie sich auf die CORS-Dokumentation.
Access-Control-Allow-Credentials
-
Gibt an, ob die Antwort für die Anfrage offengelegt werden kann, wenn das Berechtigungs-Flag wahr ist.
Access-Control-Allow-Headers
-
Wird als Antwort auf eine Vorabanfrage verwendet, um anzugeben, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden dürfen.
Access-Control-Allow-Methods
-
Gibt die Methoden an, die beim Zugriff auf die Ressource als Antwort auf eine Vorabanfrage 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 Vorabanfrage zwischengespeichert werden können.
Access-Control-Request-Headers
-
Wird beim Stellen einer Vorabanfrage verwendet, um den Server wissen zu lassen, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden.
Access-Control-Request-Method
-
Wird beim Stellen einer Vorabanfrage verwendet, um den Server wissen zu lassen, welche HTTP-Methode bei der eigentlichen Anfrage verwendet wird.
Origin
-
Gibt an, woher ein Abruf stammt.
Timing-Allow-Origin
-
Gibt Ursprünge an, die die Werte von Attributen sehen dürfen, die über Merkmale der Resource Timing API abgerufen werden. Diese Attribute würden aufgrund von Cross-Origin-Beschränkungen sonst als Null gemeldet werden.
Downloads
Content-Disposition
-
Gibt an, ob die übertragene Ressource inline angezeigt werden soll (Standardverhalten ohne den Header) oder ob sie wie ein Download behandelt werden soll und der Browser ein "Speichern unter"-Dialogfeld anzeigen soll.
Integritäts-Digests
Content-Digest
Experimentell-
Bietet einen Digest des Byte-Stroms, der in einer HTTP-Nachricht umrahmt ist (der Nachrichteninhalt), abhängig von
Content-Encoding
undContent-Range
. Digest
Veraltet Nicht standardisiert-
Bietet einen Digest einer Ressource. Siehe
Content-Digest
undRepr-Digest
. Repr-Digest
Experimentell-
Bietet einen Digest der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zum
Content-Digest
berücksichtigt der Digest nichtContent-Encoding
oderContent-Range
. Want-Content-Digest
Experimentell-
Gibt den Wunsch nach einem
Content-Digest
Header an. Es ist dasContent-
-Analogon zumWant-Repr-Digest
. Want-Digest
Veraltet Nicht standardisiert-
Gibt den Wunsch nach einem
Digest
Header an. SieheWant-Content-Digest
undWant-Repr-Digest
stattdessen. Want-Repr-Digest
Experimentell-
Gibt den Wunsch nach einem
Repr-Digest
Header an. Es ist dasRepr-
-Analogon zumWant-Content-Digest
.
Informationen zum Nachrichtenkörper
Content-Length
-
Die Größe der Ressource in dezimaler Anzahl von Bytes.
Content-Type
-
Gibt den Medientyp der Ressource an.
Content-Encoding
-
Wird verwendet, um den Kompressionsalgorithmus anzugeben.
Content-Language
-
Beschreibt die für die Zielgruppe bestimmte menschliche Sprache(n), sodass ein Benutzer nach den eigenen bevorzugten Sprachen differenzieren kann.
Content-Location
-
Gibt einen alternativen Standort für die zurückgegebenen Daten an.
Proxys
Forwarded
-
Enthält Informationen von der dem Client zugewandten Seite von Proxy-Servern, die geändert oder verloren gehen, wenn ein Proxy in den Anforderungspfad involviert ist.
Via
-
Wird von Proxys hinzugefügt, sowohl von Forward- als auch von Reverse-Proxys, und kann sowohl in den Anforderungs- als auch in den Antwort-Headern erscheinen.
Range-Anfragen
HTTP Range-Anfragen ermöglichen es dem Client, einen Teil einer Ressource von dem Server anzufordern. Range-Anfragen 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 ermöglichen, einen Download zu pausieren und fortzusetzen.
Accept-Ranges
-
Gibt an, ob der Server Range-Anfragen unterstützt, und wenn 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
-
Erstellt eine bedingte Range-Anfrage, die nur erfüllt wird, wenn der angegebene ETag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Range-Bereichen von inkompatiblen Versionen der Ressource zu verhindern.
Content-Range
-
Gibt an, wo in einer vollständigen Körper-Nachricht eine Teilnachricht hingehört.
Weiterleitungen
Location
-
Gibt die URL an, an die eine Seite weitergeleitet werden soll.
Refresh
-
Veranlasst den Browser, die Seite neu zu laden oder zu einer anderen zu weiterzuleiten. Nimmt denselben Wert wie das
meta
-Element mithttp-equiv="refresh"
.
Anforderungskontext
From
-
Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der die anfordernde Benutzer-Agent-Anwendung kontrolliert.
Host
-
Spezifiziert den Domainnamen des Servers (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server lauscht.
Referer
-
Die Adresse der vorherigen Webseite, von der ein Link zur derzeit angeforderten Seite gefolgt wurde.
Referrer-Policy
-
Regelt, welche Referrer-Informationen, die im
Referer
Header gesendet werden, sollten bei Anfragen enthalten sein. User-Agent
-
Enthält eine charakteristische Zeichenfolge, die es den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwarehersteller oder die Softwareversion des anfordernden Benutzer-Agent zu identifizieren.
Antwortkontext
Sicherheit
Cross-Origin-Embedder-Policy
(COEP)-
Ermöglicht einem Server, eine Embedding-Policy für ein bestimmtes Dokument zu deklarieren.
Cross-Origin-Opener-Policy
(COOP)-
Verhindert, dass andere Domains ein Fenster öffnen/kontrollieren können.
Cross-Origin-Resource-Policy
(CORP)-
Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch den CORP-Erklärungsartikel.
Content-Security-Policy
(CSP)-
Kontrolliert Ressourcen, die der Benutzer-Agent für eine gegebene Seite laden darf.
Content-Security-Policy-Report-Only
-
Ermöglicht es Webentwicklern, die Auswirkungen von Richtlinien durch Überwachung, jedoch nicht Durchsetzung, zu testen. 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 den Gebrauch von falsch ausgestellten Zertifikaten für diese Seite zu erkennen.
Permissions-Policy
-
Bietet einen Mechanismus zum Erlauben und Verweigern der Nutzung von Browserfunktionen in einem eigenen Frame der Webseite und in
<iframe>
s, die es einbettet. Reporting-Endpoints
Experimentell-
Antwort-Header, der es Website-Eigentümern ermöglicht, einen oder mehrere Endpunkte anzugeben, die verwendet werden, um Fehler wie CSP-Verletzungsberichte,
Cross-Origin-Opener-Policy
-Berichte, oder andere generische Verstöße zu empfangen. Strict-Transport-Security
(HSTS)-
Erzwingt die Kommunikation über HTTPS anstatt HTTP.
Upgrade-Insecure-Requests
-
Sendet ein Signal an den Server, die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort auszudrücken und dass er erfolgreich die
upgrade-insecure-requests
Richtlinie verarbeiten kann. X-Content-Type-Options
-
Deaktiviert MIME-Sniffing und zwingt den Browser, den im
Content-Type
angegebenen Typ zu verwenden. X-Frame-Options
(XFO)-
Gibt an, ob ein Browser eine Seite in einem
<frame>
,<iframe>
,<embed>
oder<object>
rendern darf. X-Permitted-Cross-Domain-Policies
-
Gibt an, ob eine Cross-Domain-Policy-Datei (
crossdomain.xml
) erlaubt ist. Die Datei kann eine Richtlinie definieren, um Clients wie Adobe's Flash Player (jetzt obsolet), Adobe Acrobat, Microsoft Silverlight (jetzt obsolet) oder Apache Flex die Erlaubnis zu erteilen, Daten über Domains hinweg zu handhaben, die aufgrund der Same-Origin Policy anderweitig beschränkt wären. Siehe die Cross-domain Policy File Specification für weitere Informationen. X-Powered-By
-
Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über sie, bietet jedoch keinen Nutzen für die Anwendung oder ihre Besucher. Löschen Sie diesen Header, um potenzielle Schwachstellen nicht offenzulegen.
X-XSS-Protection
-
Aktiviert die Filterung gegen 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 stammt und wie die Ressource verwendet wird, zulässig sein sollte.
Sec-Fetch-Site
-
Gibt die Beziehung zwischen dem Urheber einer Anfrage und ihrem Ziel an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token mit möglichen Werten
cross-site
,same-origin
,same-site
undnone
ist. Sec-Fetch-Mode
-
Gibt den Modus der Anfrage an einen Server an. Es ist ein strukturierter Header, dessen Wert ein Token mit möglichen Werten
cors
,navigate
,no-cors
,same-origin
undwebsocket
ist. Sec-Fetch-User
-
Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktivierung ausgelöst wurde oder nicht. Es handelt sich um einen strukturierten Header, dessen Wert ein Boolean ist, sodass die möglichen Werte
?0
für falsch und?1
für wahr sind. Sec-Fetch-Dest
-
Gibt das Ziel der Anfrage an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token mit möglichen Werten
audio
,audioworklet
,document
,embed
,empty
,font
,image
,manifest
,object
,paintworklet
,report
,script
,serviceworker
,sharedworker
,style
,track
,video
,worker
undxslt
ist.
Die folgenden Anforderungsheader sind nicht streng genommen "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 anzupassen:
Sec-Purpose
-
Gibt den Zweck der Anfrage an, wenn dieser Zweck etwas anderes als die unmittelbare Nutzung durch den Benutzer-Agent ist. Der Header hat derzeit einen möglichen Wert,
prefetch
, was bedeutet, dass die Ressource vorzeitig für eine mögliche zukünftige Navigation abgerufen wird. -
Ein Anforderungsheader, der bei einer präemptiven Anfrage gesendet wird, um eine Ressource während des Starts eines Service Workers zu
fetch()
. Der Wert, der mitNavigationPreloadManager.setHeaderValue()
gesetzt wird, kann verwendet werden, um einen Server zu informieren, dass eine andere Ressource als in einer normalenfetch()
-Operation zurückgegeben werden sollte.
Server-gesendete Ereignisse
Reporting-Endpoints
-
Antwort-Header, der verwendet wird, um Server-Endpunkte anzugeben, an die der Browser Warnungen und Fehlerberichte senden soll, wenn die Reporting API verwendet wird.
Report-To
Veraltet Nicht standardisiert-
Antwort-Header, der verwendet wird, um Server-Endpunkte anzugeben, an die der Browser Warnungen und Fehlerberichte senden soll, wenn die Reporting API verwendet wird.
Übertragungscodierung
Transfer-Encoding
-
Spezifiziert die Form der Kodierung, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.
TE
-
Gibt die Übertragungskodierungen an, die der Benutzer-Agent akzeptieren möchte.
Trailer
-
Ermöglicht dem Absender, zusätzliche Felder am Ende einer gestückelten Nachricht einzufügen.
WebSockets
Header, die von der WebSockets API beim WebSocket-Handshake verwendet werden:
Sec-WebSocket-Accept
-
Antwort-Header, 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 sie die von Server aus den Präferenzen des Clients ausgewählte Erweiterung an.
Sec-WebSocket-Key
-
Anforderungsheader enthält einen Schlüssel, der bestätigt, dass der Client ausdrücklich beabsichtigt, eine
WebSocket
zu öffnen. Sec-WebSocket-Protocol
-
In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten Sub-Protokolle an. In Antworten gibt sie das vom Server aus den Präferenzen des Clients ausgewählte Sub-Protokoll an.
Sec-WebSocket-Version
-
In Anfragen gibt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird sie nur gesendet, wenn die angeforderte Protokollversion nicht vom Server unterstützt wird, und listet die vom Server unterstützten Versionen auf.
Sonstige
Alt-Svc
-
Wird verwendet, um alternative Möglichkeiten 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, eine oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML
<link>
Element. Retry-After
-
Gibt an, wie lange der Benutzer-Agent warten sollte, bevor er eine Folgeanforderung stellt.
Server-Timing
-
Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anforderungs-Antwort-Zyklus.
Service-Worker-Allowed
-
Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header in der Antwort auf das Service Worker-Skript enthalten ist.
SourceMap
-
Verknüpft generierten Code mit einer Source Map.
Upgrade
-
Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung zu einem anderen Protokoll zu ändern (über dasselbe Transportprotokoll). Zum Beispiel kann es 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 einen WebSocket umzuwandeln.
Priority
-
Bietet einen Hinweis auf die Priorität eines bestimmten Ressourcenanforderungs bei einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzuzeigen, oder in einer Antwort, wenn der Server sich entscheidet, die Anfrage neu zu priorisieren.
Experimentelle Header
Attribution Reporting Headers
Die Attribution Reporting API ermöglicht Entwicklern die Messung von Konversionen – zum Beispiel, wenn ein Benutzer auf eine in eine Webseite eingebettete Anzeige klickt und dann auf der Verkäuferseite den Artikel kauft – und dann Zugriff auf Berichte zu diesen Konversionen zu erhalten. Dies geschieht ohne sich auf Drittanbieter-Tracking-Cookies zu verlassen. Stattdessen wird auf verschiedene Header zurückgegriffen, um Quellen und Trigger zu registrieren, die gematcht werden, um eine Konversion anzuzeigen.
Attribution-Reporting-Eligible
-
Wird verwendet, um anzuzeigen, dass die Antwort, die der aktuellen Anfrage entspricht, berechtigt ist, an der Attribution-Registrierung teilzunehmen, indem entweder eine Attribution-Quelle oder ein Trigger registriert werden.
Attribution-Reporting-Register-Source
-
Wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen
Attribution-Reporting-Eligible
Header enthielt, dies wird verwendet, um eine Attributionsquelle zu registrieren. Attribution-Reporting-Register-Trigger
-
Wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen
Attribution-Reporting-Eligible
Header enthielt, dies wird verwendet, um einen Attribution-Trigger zu registrieren.
Client-Hinweise
HTTP Client-Hinweise sind eine Reihe von Anforderungsheadern, die nützliche Informationen über den Client, wie Gerätetyp und Netzwerkbedingungen, bieten und es Servern ermöglichen, zu optimieren, was für diese Bedingungen bereitgestellt wird.
Server fordern proaktiv die vom Client gewünschten Client-Hinweis-Header mit Accept-CH
an. Der Client kann dann wählen, ob er die angeforderten Header in nachfolgende Anfragen einbeziehen möchte.
Accept-CH
-
Server können Unterstützung für Client-Hinweise durch das
Accept-CH
Headerfeld oder ein äquivalentes HTML<meta>
Element mit demhttp-equiv
Attribut ankündigen. Critical-CH
Experimentell-
Server verwenden
Critical-CH
zusammen mitAccept-CH
, um anzugeben, dass akzeptierte Client-Hinweise auch kritische Client-Hinweise sind.
Die verschiedenen Kategorien von Client-Hinweisen sind unten aufgeführt.
User-Agent-Client-Hinweise
Die UA-Client-Hinweise sind Anforderungsheader, die Informationen über den Benutzer-Agent, die Plattform/Architektur, auf der er läuft, und Benutzerpräferenzen, die im Benutzer-Agent oder der Plattform eingestellt sind, bereitstellen:
Sec-CH-UA
Experimentell-
Marken- und Versionsangaben des Benutzer-Agents.
Sec-CH-UA-Arch
Experimentell-
Unterliegende Plattformarchitektur des Benutzer-Agents.
Sec-CH-UA-Bitness
Experimentell-
CPU-Architektur-Bitness des Benutzer-Agents (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factor
Experimentell-
Formfaktoren des Benutzer-Agents, die beschreiben, wie der Benutzer mit dem Benutzer-Agent interagiert.
Sec-CH-UA-Full-Version
Veraltet-
Vollständiger Versionsstring des Benutzer-Agents.
Sec-CH-UA-Full-Version-List
Experimentell-
Vollständige Version für jede Marke in der Markenliste des Benutzer-Agents.
Sec-CH-UA-Mobile
Experimentell-
Der Benutzer-Agent läuft auf einem mobilen Gerät oder bevorzugt, im Allgemeinen, eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model
Experimentell-
Gerätemodell des Benutzer-Agents.
Sec-CH-UA-Platform
Experimentell-
Unterliegendes Betriebssystem/Plattform des Benutzer-Agents.
Sec-CH-UA-Platform-Version
Experimentell-
Unterliegende Betriebssystemversion des Benutzer-Agents.
Sec-CH-UA-WoW64
Experimentell-
Ob das Benutzer-Agent-Binärfile im 32-Bit-Modus auf 64-Bit-Windows läuft oder nicht.
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 Content-Layout-Verschiebungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency
Experimentell-
Anforderungsheader gibt die Präferenz des Benutzer-Agents für reduzierte Transparenz an.
Hinweis: User-Agent-Client-Hinweise sind nicht innerhalb von fenced frames verfügbar, da sie sich auf die permissions policy-Delegation verlassen, welche verwendet werden könnte, um Daten zu leaken.
Gerät-Client-Hinweise
Content-DPR
Veraltet Nicht standardisiert-
Antwort-Header wird verwendet, um das Bildgerät zu Pixelverhältnis (DPR) in Anfragen zu bestätigen, bei denen der Bildschirm-
DPR
Client-Hinweis verwendet wurde, um eine Bildquelle auszuwählen. Device-Memory
-
Ungefähre Menge des verfügbaren RAM-Speichers des Clients. Dies ist Teil der Device Memory API.
DPR
Veraltet Nicht standardisiert-
Anforderungsheader, der das Pixelverhältnis des Client-Geräts angibt (die Anzahl der physischen Geräte-Pixel für jedes CSS-Pixel).
Viewport-Width
Veraltet Nicht standardisiert-
Anforderungsheader liefert die Layout-Viewport-Breite des Clients in CSS-Pixeln.
Width
Veraltet Nicht standardisiert-
Anforderungsheader gibt die gewünschte Ressourcenbreite in physischen Pixeln an (die intrinsische Größe eines Bildes).
Netzwerk-Client-Hinweise
Netzwerk-Client-Hinweise erlauben einem Server zu wählen, welche Informationen basierend auf der Benutzerentscheidung und der Netzwerkbandbreite und -latenz gesendet wird.
Downlink
Experimentell-
Ungefähre Bandbreite der Verbindung des Clients zum Server, in Mbps. Dies ist Teil der Network Information API.
ECT
Experimentell-
Der effektive Verbindungstyp ("Netzwerkprofil"), der am besten mit der Latenz und Bandbreite der Verbindung übereinstimmt. Dies ist Teil der Network Information API.
RTT
Experimentell-
Round Trip Time (RTT) auf Anwendungsebene in Millisekunden, die die Serververarbeitungszeit einschließt. Dies ist Teil der Network Information API.
Save-Data
Experimentell-
Ein String
on
, der die Präferenz des Benutzer-Agents für geringeren Datenverbrauch angibt.
Datenschutz
DNT
Veraltet Nicht standardisiert-
Anforderungsheader, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Veraltet zugunsten von Global Privacy Control (GPC), die Servern mithilfe des
Sec-GPC
Headers kommuniziert wird und für Clients übernavigator.globalPrivacyControl
erreichbar ist. Tk
Veraltet Nicht standardisiert-
Antwort-Header, 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 einer Website oder einem Dienst zustimmt, seine persönlichen Informationen an Dritte zu verkaufen oder zu teilen.
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 erlaubt, eine Netzwerkerfehler-Berichtsrichtlinie zu deklarieren.
Topics API
Die Topics API stellt einen Mechanismus zur Verfügung, der es Entwicklern ermöglicht, Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. Sehen Sie die Topics API Dokumentation für weitere Informationen.
Observe-Browsing-Topics
Experimentell Nicht standardisiert-
Antwort-Header, der verwendet wird, um Themen von Interesse zu markieren, die von der URL einer aufrufenden Webseite im Rahmen der Antwort auf eine von einer Feature, das die Topics API aktiviert generierte Anfrage beobachtet werden.
Sec-Browsing-Topics
Experimentell Nicht standardisiert-
Anforderungsheader, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet und von einer Anzeigenplattform verwendet wird, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.
Andere
Accept-Signature
Experimentell-
Ein Client kann das
Accept-Signature
Headerfeld senden, um die Absicht anzuzeigen, sich auf verfügbare Signaturen zu stützen, und um anzugeben, welche Arten von Signaturen unterstützt werden. Early-Data
Experimentell-
Gibt an, dass die Anfrage in TLS frühzeitigen Daten übermittelt wurde.
Origin-Agent-Cluster
Experimentell-
Antwort-Header, der verwendet wird, um anzuzeigen, dass das zugehörige
Document
in einen ursprungsbezogenen Agenten-Cluster platziert werden sollte. Diese Isolation ermöglicht es Benutzer-Agenten, Implementierungsspezifische Ressourcen für Agenten-Cluster, wie Prozesse oder Threads, effizienter zuzuweisen. Set-Login
Experimentell-
Antwort-Header, gesendet von einem föderierten Identitätsanbieter (IdP), um seinen Anmeldestatus zu setzen, was bedeutet, ob Benutzer im aktuellen Browser beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und über die FedCM API verwendet.
Signature
Experimentell-
Das
Signature
Headerfeld vermittelt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie man die Autorität der Signatur feststellt und wie diese aktualisiert werden kann. Signed-Headers
Experimentell-
Das
Signed-Headers
Headerfeld identifiziert eine geordnete Liste von Antwort-Headerfeldern, die in einer Signatur einbezogen werden sollen. Speculation-Rules
Experimentell-
Bietet eine Liste von URLs, die auf Textressourcen zeigen, die Speculation Rule JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregel-Set des Dokuments hinzugefügt.
Supports-Loading-Mode
Experimentell-
Wird von einem Navigationstarget gesetzt, um die Verwendung verschiedener risikoreicher Lade-Modi zu ermöglichen. Zum Beispiel erfordert das Prerendering von Cross-Origin, Same-Site prerendering einen
Supports-Loading-Mode
Wert voncredentialed-prerender
.
Nicht-standardisierte Header
X-Forwarded-For
Nicht standardisiert-
Identifiziert die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder einen Load-Balancer eine Verbindung zu einem Webserver herstellt.
X-Forwarded-Host
Nicht standardisiert-
Identifiziert den ursprünglichen Host, der von einem Client verwendet wurde, um eine Verbindung zu Ihrem Proxy oder Load-Balancer herzustellen.
X-Forwarded-Proto
Nicht standardisiert-
Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Load-Balancer herzustellen.
X-DNS-Prefetch-Control
Nicht standardisiert-
Kontrolliert das DNS-Vorababrufen, eine Funktion, durch die Browser proaktiv die Domainauflösung sowohl für Links vornehmen, denen der Benutzer folgen könnte, als auch für URLs, die vom Dokument referenziert werden, einschließlich Bildern, CSS, JavaScript usw.
X-Robots-Tag
Nicht standardisiert-
Der
X-Robots-Tag
HTTP-Header wird verwendet, um anzuzeigen, wie eine Webseite in öffentlichen Suchmaschinenergebnissen indexiert werden soll. Der Header ist effektiv äquivalent zu<meta name="robots" content="…">
.
Veraltete Header
Pragma
Veraltet-
Implementierungsspezifischer Header, der verschiedene Effekte an jeder Stelle in der Anforderungs-/Antwortkette haben kann. Wird für die Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, wo der
Cache-Control
Header noch nicht vorhanden ist. Warning
Veraltet-
Allgemeiner Warnhinweis über mögliche Probleme.
Mitwirken
Sie können helfen, indem Sie neue Einträge schreiben oder bestehende Einträge verbessern.