HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort zu senden. In HTTP/1.X besteht ein Header aus einem nicht case-sensitiven Namen, gefolgt von einem Doppelpunkt, optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header kleingeschrieben angezeigt, wenn sie in Entwicklertools betrachtet werden (accept: */*) und mit einem Doppelpunkt für eine spezielle Gruppe von Pseudo-Headern versehen (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden historisch mit einem X- Präfix verwendet, aber diese Konvention wurde 2012 wegen der Unannehmlichkeiten, die auftraten, wenn nicht standardmäßige Felder standardisiert wurden, in RFC 6648 abgeschafft; andere sind im IANA HTTP Field Name Registry aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert war. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status.

Header können je nach ihrem Kontext gruppiert werden:

Anfrage-Header

Enthalten weitere Informationen über die anzufordernde Ressource oder über den Client, der die Ressource anfordert.

Antwort-Header

Halten zusätzliche Informationen über die Antwort, wie ihren Standort oder über den Server, der sie bereitstellt.

Darstellungs-Header

Enthalten Informationen über den Hauptteil der Ressource, wie ihren MIME-Typ oder die angewendete Kodierung/Kompression.

Nutzdaten-Header

Enthalten darstellungsunabhängige Informationen über Nutzdaten, einschließlich Inhaltlänge und der für den Transport verwendeten Kodierung.

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

End-to-End-Header

Diese Header müssen an den endgültigen Empfänger der Nachricht übermittelt werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenproxies müssen diese Header unverändert weiterleiten und Caches müssen sie speichern.

Hop-by-Hop-Header

Diese Header sind nur für eine einzelne Transportverbindung sinnvoll und dürfen nicht von Proxies weiterübertragen oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mithilfe des Connection-Headers eingestellt werden können.

Authentifizierung

WWW-Authenticate

Definiert die Authentifizierungsmethode, die zur Zugriffsberechtigung auf eine Ressource verwendet werden soll.

Authorization

Enthält die Anmeldedaten, um einen User-Agent bei einem Server zu authentifizieren.

Proxy-Authenticate

Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden soll.

Proxy-Authorization

Enthält die Anmeldedaten, um einen User-Agent bei einem Proxy-Server zu authentifizieren.

Zwischenspeicherung

Age

Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache gewesen ist.

Cache-Control

Direktiven für Caching-Mechanismen in sowohl Anfragen als auch Antworten.

Clear-Site-Data

Löscht Browsing-Daten (z.B. Cookies, Speicher, Cache), die der anfordernden Website zugeordnet sind.

Expires

Das Datum/die Uhrzeit, nach der die Antwort als veraltet betrachtet wird.

Gibt eine Reihe von Regeln an, die definieren, wie die Abfrageparameter einer URL das Cache-Matching beeinflussen. Diese Regeln bestimmen, ob die gleiche URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Bedingungen

Last-Modified

Das Datum der letzten Änderung der Ressource, verwendet, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau als ETag, aber einfacher in manchen Umgebungen zu berechnen. Bedingte Anfragen mit If-Modified-Since und If-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.

ETag

Eine eindeutige Zeichenfolge, die die Version der Ressource identifiziert. Bedingte Anfragen mit If-Match und If-None-Match verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.

If-Match

Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.

If-None-Match

Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource nicht mit einem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen) oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine vorhanden ist.

If-Modified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur dann übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur zu übertragen, wenn der Cache veraltet ist.

If-Unmodified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur dann übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies gewährleistet die Kohärenz eines neuen Abschnitts eines spezifischen Bereichs mit vorherigen oder um ein optimistisches Parallelitätskontrollsystem bei der Änderung bestehender Dokumente umzusetzen.

Vary

Bestimmt, wie Anforderungs-Header übereinstimmen sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.

Verbindungsmanagement

Connection

Kontrolliert, ob die Netzwerkverbindung offen bleibt, nachdem die aktuelle Transaktion abgeschlossen ist.

Keep-Alive

Kontrolliert, wie lange eine persistente Verbindung geöffnet bleiben soll.

Inhaltsaushandlung

Für weitere Informationen siehe den Artikel zur Inhaltsaushandlung.

Accept

Informiert den Server über die Typen von Daten, die zurückgesendet werden können.

Accept-Encoding

Der Kodierungsalgorithmus, normalerweise ein Kompressionsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.

Accept-Language

Informiert den Server über die menschliche Sprache, die vom Server zurückgesendet werden soll. Dies ist ein Hinweis und liegt nicht unbedingt vollständig unter der Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerwahl nicht zu überschreiben (wie die Auswahl einer Sprache aus einem Dropdown-Menü).

Accept-Patch

Ein Anfrage-Inhaltsaushandlung-Antwortheader, der anzeigt, welche Medientypen der Server in einer PATCH-Anfrage verstehen kann.

Accept-Post

Ein Anfrage-Inhaltsaushandlung-Antwortheader, der anzeigt, welche Medientypen der Server in einer POST-Anfrage verstehen kann.

Steuerungen

Expect

Zeigt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.

Max-Forwards

Gibt bei Verwendung von TRACE die maximale Anzahl von Hops an, die die Anfrage machen kann, bevor sie zum Absender zurückgespiegelt wird.

Cookies

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

Sendet Cookies vom Server an den User-Agent.

CORS

Für weitere Informationen siehe die CORS-Dokumentation.

Access-Control-Allow-Credentials

Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn die Anmeldeflagge wahr ist.

Access-Control-Allow-Headers

Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzuzeigen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden können.

Access-Control-Allow-Methods

Gibt die Methoden an, die beim Zugriff auf die Ressource als Antwort auf eine Preflight-Anfrage erlaubt sind.

Access-Control-Allow-Origin

Gibt an, ob die Antwort geteilt werden kann.

Access-Control-Expose-Headers

Gibt an, welche Header als Teil der Antwort offengelegt werden können, indem ihre Namen aufgelistet werden.

Access-Control-Max-Age

Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage im Cache gespeichert werden können.

Access-Control-Request-Headers

Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.

Access-Control-Request-Method

Wird verwendet, wenn eine Preflight-Anfrage erstellt wird, um dem Server mitzuteilen, welche HTTP-Methode bei der tatsächlichen Anfrage verwendet wird.

Origin

Gibt an, von wo eine Übertragung ausgeht.

Timing-Allow-Origin

Gibt Ursprünge an, die berechtigt sind, Werte von Attributen zu sehen, die über Funktionen der Resource Timing API abgerufen werden, die andernfalls aufgrund von Beschränkungen bei der Ursprungsübergreifung als null gemeldet werden würden.

Downloads

Content-Disposition

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

Integritäts-Hashes

Content-Digest Experimentell

Stellt einen Hash des im Http-Nachrichtenrumpf umrahmten Oktettstroms (dem Nachrichteninhalt) abhängig von Content-Encoding und Content-Range bereit.

Repr-Digest Experimentell

Stellt einen Hash der ausgewählten Repräsentation der Zielressource vor der Übertragung bereit. Im Gegensatz zum Content-Digest berücksichtigt der Hash ikke Content-Encoding oder Content-Range.

Want-Content-Digest Experimentell

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

Want-Repr-Digest Experimentell

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

Nachrichtenteilkörper-Informationen

Content-Length

Die Größe der Ressource in Dezimalzahl der Bytes.

Content-Type

Gibt den Medientyp der Ressource an.

Content-Encoding

Wird verwendet, um den Kompressionsalgorithmus anzugeben.

Content-Language

Beschreibt die menschliche Sprache(n), die für das Publikum bestimmt sind, so dass es einem Benutzer ermöglicht, je nach der bevorzugten Sprache zu unterscheiden.

Content-Location

Gibt einen alternativen Ort für die zurückgegebenen Daten an.

Proxies

Forwarded

Enthält Informationen von der dem Client zugewandten Seite der Proxy-Server, die verändert oder verloren gehen, wenn ein Proxy im Pfad der Anfrage beteiligt ist.

Via

Hinzugefügt von Proxies, sowohl Vorwärts- als auch Rückwärts-Proxies, und kann in Anfrage-Headern und Antwort-Headern auftreten.

Bereichsanfragen

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

Accept-Ranges

Gibt an, ob der Server Bereichsanfragen unterstützt und in welcher Einheit der Bereich ausgedrückt werden kann.

Range

Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.

If-Range

Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn das gegebene Etag oder Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen aus einer inkompatiblen Version der Ressource zu verhindern.

Content-Range

Gibt an, wo in einer vollständigen Nachricht ein Teil einer Nachricht gehört.

Umleitungen

Location

Gibt die URL an, zu der eine Seite umgeleitet werden soll.

Refresh

Weist den Browser an, die Seite neu zu laden oder an eine andere weiterzuleiten. Nimmt denselben Wert an wie das meta-Element mit http-equiv="refresh".

Anfragekontext

From

Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden User-Agent steuert.

Host

Gibt den Domainnamen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server hört.

Referer

Die Adresse der vorherigen Webseite, von der aus ein Link zur aktuell angeforderten Seite gefolgt wurde.

Referrer-Policy

Bestimmt, welche Referrer-Informationen im Referer-Header mit Anfragen gesendet werden sollen.

User-Agent

Enthält eine charakteristische Zeichenfolge, die es den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfordernden Software-User-Agents zu identifizieren.

Antwortkontext

Allow

Listet die Menge der HTTP-Anfragemethoden auf, die von einer Ressource unterstützt werden.

Server

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

Sicherheit

Cross-Origin-Embedder-Policy (COEP)

Ermöglicht einem Server, eine Einbettungspolitik für ein gegebenes Dokument zu deklarieren.

Cross-Origin-Opener-Policy (COOP)

Verhindert, dass andere Domains ein Fenster öffnen/steuern können.

Cross-Origin-Resource-Policy (CORP)

Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch CORP-Erklärerartikel.

Content-Security-Policy (CSP)

Steuert, welche Ressourcen der User-Agent für eine bestimmte Seite laden darf.

Content-Security-Policy-Report-Only

Erlaubt Webentwicklern, mit Richtlinien zu experimentieren, indem die Auswirkungen überwacht, aber nicht erzwungen werden. Diese Verstoßberichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.

Expect-CT Veraltet

Ermöglicht es Seiten, sich für die Berichterstattung und Durchsetzung von Zertifikatstransparenz zu entscheiden, um die Verwendung von falsch ausgestellten Zertifikaten für diese Seite zu erkennen.

Permissions-Policy

Bietet einen Mechanismus, um die Verwendung von Browserfunktionen in einem eigenen Rahmen der Website zuzulassen und zu verweigern, sowie in <iframe>s, die eingebettet sind.

Reporting-Endpoints Experimentell

Antwortheader, der es Websitebesitzern erlaubt, einen oder mehrere Endpunkte anzugeben, die verwendet werden sollen, um Fehler wie CSP-Verstoßberichte, Cross-Origin-Opener-Policy-Berichte oder andere allgemeine Verstöße zu erhalten.

Strict-Transport-Security (HSTS)

Erzwingen der Kommunikation über HTTPS anstelle von HTTP.

Upgrade-Insecure-Requests

Sendet ein Signal an den Server, das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt und dass er erfolgreich die upgrade-insecure-requests-Direktive behandeln kann.

X-Content-Type-Options

Deaktiviert das MIME-Sniffing und zwingt den Browser, den im Content-Type-Header angegebenen Typ zu verwenden.

X-Frame-Options (XFO)

Gibt an, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern darf.

X-Permitted-Cross-Domain-Policies

Eine Cross-Domain-Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domains hinweg zu verarbeiten, die sonst aufgrund der Same-Origin-Policy eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients weiterhin unerwünschte Anfragen blockieren.

X-Powered-By

Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, während sie jedoch keinen Nutzen für die Anwendung oder deren Besucher bietet. Entfernen Sie diesen Header, um potenzielle Schwachstellen nicht offenzulegen.

X-XSS-Protection

Aktiviert das Cross-Site-Scripting-Filtering.

Fetch-Metadaten-Anforderungsheader

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

Sec-Fetch-Site

Gibt die Beziehung zwischen dem Ursprungsort eines Anforderungsinitiators und dem Ursprungsort seines Ziels an. Es ist ein strukturierter Header, dessen Wert ein Token mit den möglichen Werten cross-site, same-origin, same-site und none ist.

Sec-Fetch-Mode

Gibt den Modus der Anfrage an einen Server an. Es ist ein strukturierter Header, dessen Wert ein Token mit den möglichen Werten cors, navigate, no-cors, same-origin und websocket ist.

Sec-Fetch-User

Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktivierung ausgelöst wurde oder nicht. Es ist ein strukturierter Header, dessen Wert ein boolescher Wert ist, daher sind die möglichen Werte ?0 für falsch und ?1 für wahr.

Sec-Fetch-Dest

Gibt das Ziel der Anfrage an. Es ist ein strukturierter Header, dessen Wert ein Token mit den möglichen Werten audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker und xslt ist.

Die folgenden Anforderungsheader sind nicht strikt "Fetch-Metadaten-Anforderungsheader", liefern jedoch ähnlich Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten zu ändern oder die zurückgegebenen Informationen:

Sec-Purpose

Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als die unmittelbare Nutzung durch den User-Agent ist. Der Header hat derzeit einen möglichen Wert, prefetch, der anzeigt, dass die Ressource zur Vorbereitung einer möglichen zukünftigen Navigation vorab abgerufen wird.

Service-Worker-Navigation-Preload

Ein Anforderungsheader, der in einer vorzeitigen Anfrage gesendet wird, um fetch() eine Ressource während des Dienst-Worker-Boots abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() festgelegt wird, kann verwendet werden, um einen Server zu informieren, dass eine andere Ressource zurückgegeben werden soll als in einem normalen fetch()-Vorgang.

Server-sent events

Reporting-Endpoints

Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an denen der Browser Warn- und Fehlermeldungen beim Verwenden der Reporting API senden soll.

Report-To Veraltet Nicht standardisiert

Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an denen der Browser Warn- und Fehlermeldungen beim Verwenden der Reporting API senden soll.

Übertragungscodierung

Transfer-Encoding

Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.

TE

Gibt die Übertragungscodierungen an, die der User-Agent bereit ist anzunehmen.

Trailer

Erlaubt es dem Absender, zusätzliche Felder am Ende einer gestückelten Nachricht einzuschließen.

WebSockets

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

Sec-WebSocket-Accept

Antwortheader, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung zu wechseln.

Sec-WebSocket-Extensions

In Anfragen zeigt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten zeigt er die vom Server aus den Präferenzen des Clients ausgewählte Erweiterung an.

Sec-WebSocket-Key

Anforderungsheader, der einen Schlüssel enthält, der überprüft, dass der Client ausdrücklich beabsichtigt, einen WebSocket zu öffnen.

Sec-WebSocket-Protocol

In Anfragen zeigt dieser Header die vom Client unterstützten Subprotokolle in bevorzugter Reihenfolge an. In Antworten zeigt er das vom Server aus den Präferenzen des Clients ausgewählte Subprotokoll an.

Sec-WebSocket-Version

In Anfragen zeigt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn die angeforderte Protokollversion vom Server nicht unterstützt wird und listet die vom Server unterstützten Versionen auf.

Andere

Alt-Svc

Wird verwendet, um alternative Möglichkeiten zur Erreichung dieses Dienstes aufzulisten.

Alt-Used

Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.

Date

Enthält das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde.

Dieses Entität-Header-Feld bietet eine Möglichkeit, einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML-<link>-Element.

Retry-After

Gibt an, wie lange der User-Agent warten soll, bevor eine Folgeanfrage gestellt wird.

Server-Timing

Kommuniziert eine oder mehrere Metriken und Beschreibungen für den angegebenen Anfrage-Antwort-Zyklus.

Service-Worker

Wird bei Abrufen für die Ressource eines Service Workers eingeschlossen. Diese Header hilft Administratoren, Anfragen für das Service-Worker-Skript zu protokollieren, um Überwachungszwecke zu erfüllen.

Service-Worker-Allowed

Wird verwendet, um die Pfadbeschränkung durch das Einschließen dieses Headers in der Antwort des Service Worker-Skripts zu entfernen.

SourceMap

Verknüpft mit einer Source Map, damit Debugger durch ursprünglich geschriebenen Quellcode anstelle von generiertem oder transformiertem Code gehen können.

Upgrade

Dieser HTTP/1.1 (nur)-Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung auf ein anderes Protokoll (über das gleiche Transportprotokoll) zu aktualisieren. Zum Beispiel kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 zu HTTP 2.0 zu aktualisieren oder eine HTTP- oder HTTPS-Verbindung in ein WebSocket.

Priority

Liefert einen Hinweis auf die Priorität einer bestimmten Ressourcenanfrage auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzuzeigen oder in einer Antwort, wenn der Server entscheidet, die Anfrage neu zu priorisieren.

Experimentelle Header

Attributbericht-Header

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

Attribution-Reporting-Eligible

Wird verwendet, um anzuzeigen, dass die Antwort auf die aktuelle Anfrage berechtigt ist, an der Attributberichterstattung teilzunehmen, indem entweder eine Attributquelle oder ein Auslöser registriert wird.

Attribution-Reporting-Register-Source

Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, verwendet, um eine Attributquelle zu registrieren.

Attribution-Reporting-Register-Trigger

Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, verwendet, um einen Attributauslöser zu registrieren.

Client-Hints

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

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

Accept-CH

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

Critical-CH Experimentell

Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client-Hints auch kritische Client-Hints sind.

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

Benutzeragentur-Client-Hints

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

Sec-CH-UA Experimentell

Marken- und Versionsinformationen der Benutzeragentur.

Sec-CH-UA-Arch Experimentell

Plattformarchitektur der Benutzeragentur.

Sec-CH-UA-Bitness Experimentell

Bitbreite der zugrunde liegenden CPU-Architektur der Benutzeragentur (zum Beispiel "64" Bit).

Sec-CH-UA-Form-Factors Experimentell

Formfaktoren der Benutzeragentur, die beschreiben, wie der Benutzer mit der Benutzeragentur interagiert.

Sec-CH-UA-Full-Version Veraltet

Vollständige Versionszeichenkette der Benutzeragentur.

Sec-CH-UA-Full-Version-List Experimentell

Vollständige Version für jede Marke in der Markenliste der Benutzeragentur.

Sec-CH-UA-Mobile Experimentell

Benutzeragentur läuft auf einem mobilen Gerät oder bevorzugt allgemein eine "mobile" Benutzererfahrung.

Sec-CH-UA-Model Experimentell

Gerätemodell der Benutzeragentur.

Sec-CH-UA-Platform Experimentell

Betriebssystem/-plattform der Benutzeragentur.

Sec-CH-UA-Platform-Version Experimentell

Betriebssystem-Version der Benutzeragentur.

Sec-CH-UA-WoW64 Experimentell

Ob die Binärdatei der Benutzeragentur im 32-Bit-Modus auf 64-Bit-Windows läuft.

Sec-CH-Prefers-Color-Scheme Experimentell

Präferenz des Benutzers für dunkles oder helles Farbschema.

Sec-CH-Prefers-Reduced-Motion Experimentell

Präferenz des Benutzers, weniger Animationen und Inhaltslayoutverschiebungen zu sehen.

Sec-CH-Prefers-Reduced-Transparency Experimentell

Anforderungs-Header gibt die Präferenz der Benutzeragentur für reduzierte Transparenz an.

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

Geräte-Client-Hints

Content-DPR Veraltet Nicht standardisiert

Antwortheader zur Bestätigung des Bildgeräte-zu-Pixel-Verhältnisses (DPR) in Anfragen, bei denen der Bildschirm-DPR-Client-Hinweis verwendet wurde, um eine Bildressource auszuwählen.

Device-Memory

Ungefähre Menge an verfügbarem RAM-Speicher des Clients. Dies ist Teil der Device Memory API.

DPR Veraltet Nicht standardisiert

Anforderungsheader, der das Gerät-Pixel-Verhältnis des Clients angibt (die Anzahl der physischen Gerätepixel für jedes CSS-Pixel).

Viewport-Width Veraltet Nicht standardisiert

Anforderungs-Header bietet die Layout-Viewport-Breite des Clients in CSS-Pixel.

Width Veraltet Nicht standardisiert

Anforderungs-Header gibt die gewünschte Ressourcenbreite in physischen Pixeln an (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hints

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

Ungefähre Bandbreite der Verbindung des Clients zum Server, in Mbit/s. Dies ist Teil der Network Information API.

ECT Experimentell

Der effektive Verbindungstyp ("Netzwerkprofil"), das Latenz und Bandbreite der Verbindung am besten entspricht. Dies ist Teil der Network Information API.

RTT Experimentell

Anwendungs-Ebene Round Trip Time (RTT) in Millisekunden, welches auch die Serververarbeitungszeit umfasst. Dies ist Teil der Network Information API.

Save-Data Experimentell

Eine Zeichenfolge on, die die Datenverbrauchspräferenz der Benutzeragentur anzeigt.

Datenschutz

DNT Veraltet Nicht standardisiert

Anforderungs-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Abgelöst durch Global Privacy Control (GPC), das den Servern über den Sec-GPC-Header mitgeteilt wird und für Clients über navigator.globalPrivacyControl zugänglich ist.

Tk Veraltet Nicht standardisiert

Antwortheader, der den Trackingstatus angibt, der auf die entsprechende Anfrage angewendet wurde. Wird in Verbindung mit DNT verwendet.

Sec-GPC Nicht standardisiert Experimentell

Gibt an, ob der Benutzer zustimmt, dass eine Website oder ein Dienst ihre persönlichen Informationen an Dritte verkauft oder teilt.

Sicherheit

Origin-Agent-Cluster Experimentell

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

Server-sent events

NEL Experimentell

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

Topics API

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

Observe-Browsing-Topics Experimentell Nicht standardisiert

Antwortheader, der verwendet wird, um Themen von Interesse zu kennzeichnen, die aus der URL einer aufrufenden Site abgeleitet werden und als in der Antwort auf eine Anfrage im Rahmen eines Features, das die Topics API aktiviert, beobachtet werden.

Sec-Browsing-Topics Experimentell Nicht standardisiert

Anforderungs-Header, der die für den aktuellen Benutzer ausgewählten Themen zusammen mit der zugehörigen Anfrage sendet, die von einer Adtech-Plattform verwendet werden, um eine personalisierte Werbung auszuwählen, die angezeigt werden soll.

Andere

Accept-Signature Experimentell

Ein Client kann den Accept-Signature-Header senden, um die Absicht anzuzeigen, von verfügbaren Signaturen zu profitieren, und um anzugeben, welche Art von Signaturen er unterstützt.

Early-Data Experimentell

Gibt an, dass die Anfrage in TLS-Frühdaten übermittelt wurde.

Set-Login Experimentell

Antwortheader, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus einzurichten, was bedeutet, ob Benutzer im aktuellen Browser beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM-API verwendet.

Signature Experimentell

Der Signature-Header-Feld überträgt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität dieser Signatur bestimmt und erneuert wird.

Signed-Headers Experimentell

Der Signed-Headers-Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur einbezogen werden sollen.

Speculation-Rules Experimentell

Bietet eine Liste von URLs, die auf Textressourcen mit Spekulationsregel-JSON-Definitionen zeigen. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregelset des Dokuments hinzugefügt.

Supports-Loading-Mode Experimentell

Vom Navigationstarget gesetzt, um die Verwendung verschiedener riskanterer Lademodi zu bestätigen. Zum Beispiel erfordert co-origins, gleich-Site prerendering einen Supports-Loading-Mode Wert von credentialed-prerender.

Nicht standardisierte Header

X-Forwarded-For Nicht standardisiert

Identifiziert die ursprünglichen IP-Adressen eines Clients, der sich über einen HTTP-Proxy oder Lastenausgleicher mit einem Webserver verbindet.

X-Forwarded-Host Nicht standardisiert

Identifiziert den ursprünglichen Host, der von einem Client verwendet wurde, um sich mit Ihrem Proxy oder Lastenausgleicher zu verbinden.

X-Forwarded-Proto Nicht standardisiert

Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um sich mit Ihrem Proxy oder Lastenausgleicher zu verbinden.

X-DNS-Prefetch-Control Nicht standardisiert

Steuert das DNS-Prefetching, eine Funktion, durch die Browser proaktiv die Namensauflösung für sowohl Links, die der Benutzer möglicherweise auswählt, als auch URLs für Elemente, die vom Dokument referenziert werden, einschließlich Bilder, CSS, JavaScript usw., durchführen.

X-Robots-Tag Nicht standardisiert

Der X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb öffentlicher Suchmaschinenergebnisse indexiert werden soll. Der Header ist effektiv äquivalent zu <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet

Implementierungsspezifischer Header, der überall entlang der Anforderungs-Antwort-Kette verschiedene Effekte haben kann. Wird zur Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, wo der Cache-Control-Header noch nicht vorhanden ist.

Warning Veraltet

Allgemeine Warninformationen über mögliche Probleme.

Mitwirken

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

Siehe auch