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.

Authorization

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.

Proxy-Authorization

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.

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 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 (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 und Content-Range.

Digest Veraltet Nicht standardisiert

Bietet einen Digest einer Ressource. Siehe Content-Digest und Repr-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 nicht Content-Encoding oder Content-Range.

Want-Content-Digest Experimentell

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

Want-Digest Veraltet Nicht standardisiert

Gibt den Wunsch nach einem Digest Header an. Siehe Want-Content-Digest und Want-Repr-Digest stattdessen.

Want-Repr-Digest Experimentell

Gibt den Wunsch nach einem Repr-Digest Header an. Es ist das Repr--Analogon zum Want-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 mit http-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

Allow

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

Server

Enthält Informationen über die vom Ursprung-Server verwendete Software, um die Anfrage zu bearbeiten.

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 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 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 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 und xslt 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.

Service-Worker-Navigation-Preload

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 mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server zu informieren, dass eine andere Ressource als in einer normalen fetch()-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.

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 dem http-equiv Attribut ankündigen.

Critical-CH Experimentell

Server verwenden Critical-CH zusammen mit Accept-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.

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 über navigator.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 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 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.

Siehe auch