HTTP-Header

HTTP-Header 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 fallunterscheidenden 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 sie verursachte, wenn nicht standardisierte Felder im RFC 6648 zu Standards wurden, abgeschafft; andere sind im IANA HTTP Field Name Registry aufgelistet, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über deren Status, die "permanent" (standarddefiniert), "provisorisch" (neu), "abgelehnt" (Nutzung nicht empfohlen) oder "veraltet" (nicht mehr in Gebrauch) sein können.

Header können nach ihren Kontexten gruppiert werden:

Request-Header

Enthält zusätzliche Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.

Response-Header

Enthält zusätzliche Informationen über die Antwort, wie deren Standort oder über den sie bereitstellenden Server.

Representation-Header

Enthält Informationen über den Hauptteil der Ressource, wie deren MIME-Typ, oder angewandte Kodierung/Kompression.

Payload-Header

Enthält darstellungsunabhängige Informationen über die Nutzdateneinheit, einschließlich der Inhaltslänge und der zum Transport verwendeten Kodierung.

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

End-to-End-Header

Diese Header müssen dem endgültigen Empfänger der Nachricht übermittelt werden: dem Server für eine Anfrage oder dem Client für eine Antwort. Zwischen-Proxies 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 Transport-Level-Verbindung von Bedeutung und dürfen nicht von Proxies weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mit dem Connection-Header gesetzt werden können.

Authentifizierung

WWW-Authenticate

Definiert die Authentifizierungsmethode, die verwendet werden soll, um auf eine Ressource zuzugreifen.

Authorization

Enthält die Anmeldedaten, um einen Benutzeragenten beim Server zu authentifizieren.

Proxy-Authenticate

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

Proxy-Authorization

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

Zwischenspeicherung

Age

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

Cache-Control

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

Clear-Site-Data

Löscht Browserdaten (z.B. Cookies, Speicherung, Cache), die mit der anfordernden Website verknüpft sind.

Expires

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

Gibt einen Satz 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 Browser-Cache-Einträge gespeichert werden sollte.

Bedingte Header

Last-Modified

Das Datum der letzten Änderung der Ressource, verwendet, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau als ETag, aber in manchen Umgebungen leichter 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 gegebenen ETags übereinstimmt.

If-None-Match

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

If-Modified-Since

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

If-Unmodified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum nicht modifiziert wurde. Dies stellt die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorhergehenden Teilen sicher oder um ein optimistisches Parallelitätskontrollsystem bei der Modifikation bestehender Dokumente zu implementieren.

Vary

Bestimmt, wie Anforderungsheader abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.

Verbindungsmanagement

Connection

Kontrolliert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion geöffnet bleibt.

Keep-Alive

Kontrolliert, wie lange eine beständige Verbindung offen bleiben soll.

Inhaltsverhandlung

Weitere Details finden Sie im Artikel zur Inhaltsvereinbarung.

Accept

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

Accept-Encoding

Der Kodierungsalgorithmus, normalerweise ein Kompressionsalgorithmus, der auf der zurückgesendeten Ressource verwendet werden kann.

Accept-Language

Informiert den Server über die Sprache, die der Server zurücksenden soll. Dies ist ein Hinweis und liegt nicht notwendigerweise vollständig unter der Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerauswahl nicht zu überschreiben (wie das Auswählen einer Sprache aus einem Dropdown-Menü).

Accept-Patch

Ein Anfrage-Inhaltsverhandlung Antwortheader, der angibt, welchen Medientyp der Server in einer PATCH-Anfrage versteht.

Accept-Post

Ein Anfrage-Inhaltsverhandlung Antwortheader, der angibt, welchen Medientyp der Server in einer POST-Anfrage versteht.

Steuerungen

Expect

Gibt Erwartungen an, die der Server erfüllen muss, um die Anfrage ordnungsgemäß zu verarbeiten.

Max-Forwards

Gibt bei Verwendung von TRACE an, wie viele Hops 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 Benutzeragenten.

CORS

Weitere Informationen finden Sie in der CORS-Dokumentation.

Access-Control-Allow-Credentials

Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Anmeldeinformationen-Flag wahr ist.

Access-Control-Allow-Headers

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

Access-Control-Allow-Methods

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

Access-Control-Allow-Origin

Gibt an, ob die Antwort geteilt werden kann.

Access-Control-Expose-Headers

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

Access-Control-Max-Age

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

Access-Control-Request-Headers

Wird bei der Preflight-Anfrage verwendet, um den Server wissen zu lassen, welche HTTP-Header verwendet werden, wenn die tatsächliche Anfrage gestellt wird.

Access-Control-Request-Method

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

Origin

Gibt an, woher ein Abruf stammt.

Timing-Allow-Origin

Gibt Ursprünge an, die Berechtigung haben, Werte von Attributen abzurufen, die durch Funktionen der Resource Timing API erlangt wurden, die andernfalls aufgrund von Cross-Origin-Beschränkungen als Null gemeldet würden.

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 einen "Speichern unter"-Dialog anzeigen soll.

Integritätsprüfsummen

Content-Digest Experimentell

Stellt eine Prüfsumme des Stream von Oktetten bereit, die in einer HTTP-Nachricht (dem Nachrichteninhalt) je nach Content-Encoding und Content-Range gerahmt sind.

Digest Veraltet Nicht standardisiert

Stellt eine Prüfsumme einer Ressource bereit. Siehe Content-Digest und Repr-Digest.

Repr-Digest Experimentell

Stellt eine Prüfsumme der ausgewählten Repräsentation der Zielressource vor der Übertragung bereit. Im Gegensatz zum Content-Digest berücksichtigt die Prüfsumme weder Content-Encoding noch Content-Range.

Want-Content-Digest Experimentell

Gibt den Wunsch nach einem Content-Digest-Header an. Es ist das Content- Analogon zu 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 zu Want-Content-Digest.

Informationsaustausch zum Nachrichtenkörper

Content-Length

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

Content-Type

Gibt den Medientyp der Ressource an.

Content-Encoding

Verwendet, um den Kompressionsalgorithmus anzugeben.

Content-Language

Beschreibt die menschliche Sprache(n), die für das Publikum vorgesehen sind, sodass es einem Benutzer ermöglicht wird, nach seiner bevorzugten Sprache zu differenzieren.

Content-Location

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

Proxies

Forwarded

Enthält Informationen von der clientseitigen Seite von Proxy-Servern, die verändert oder verloren gehen, wenn ein Proxy am Weg der Anfrage beteiligt ist.

Via

Wird von Proxies, sowohl Vorwärts- als auch Rückwärts-Proxies, hinzugefügt und kann in den Anforderungs- und Antwortheadern erscheinen.

Bereichsanfragen

HTTP Bereichsanfragen ermöglichen es dem Client, ein Segment einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Mediaplayer, die zufälligen Zugriff unterstützen, Datentools, die nur einen Teil einer großen Datei benötigen, und Download-Manager, die es dem Benutzer ermöglichen, einen Download zu pausieren und fortzusetzen.

Accept-Ranges

Gibt an, ob der Server Bereichsanfragen unterstützt und, falls 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 Bereichsanfrage, die nur erfüllt wird, wenn der angegebene ETag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen von inkompatiblen Versionen der Ressource zu verhindern.

Content-Range

Gibt an, wo in einer vollständigen Nachrichtenkörper die Teilnachricht hingehö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 zu einer anderen zu leiten. Nimmt denselben Wert wie das meta-Element mit http-equiv="refresh" an.

Anforderungskontext

From

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

Host

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

Referer

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

Referrer-Policy

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

User-Agent

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

Antwortkontext

Allow

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

Server

Enthält Informationen über die Software, die vom Ursprungsserver zur Bearbeitung der Anfrage verwendet wird.

Sicherheit

Cross-Origin-Embedder-Policy (COEP)

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

Cross-Origin-Opener-Policy (COOP)

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

Cross-Origin-Resource-Policy (CORP)

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

Content-Security-Policy (CSP)

Kontrolliert Ressourcen, die der Benutzeragent für eine gegebene Seite laden darf.

Content-Security-Policy-Report-Only

Ermöglicht es Webentwicklern, mit Richtlinien zu experimentieren, indem sie deren Auswirkungen überwachen, aber nicht durchsetzen. Diese Verstoßberichte 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 die Verwendung von falsch ausgestellten Zertifikaten für diese Site zu erkennen.

Permissions-Policy

Bietet einen Mechanismus zum Erlauben oder Verweigern der Nutzung von Browserfunktionen im eigenen Rahmen einer Website und in <iframe>s, die sie einbettet.

Reporting-Endpoints Experimentell

Antwortheader, der es Website-Besitzern ermöglicht, einen oder mehrere Endpunkte anzugeben, die zur Empfang von Fehlern wie CSP-Verletzungsberichten, Cross-Origin-Opener-Policy-Berichten oder anderen allgemeinen Verstößen verwendet werden.

Strict-Transport-Security (HSTS)

Erzwingt die Kommunikation über HTTPS statt HTTP.

Upgrade-Insecure-Requests

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

X-Content-Type-Options

Deaktiviert das MIME-Sniffing und erzwingt, dass der Browser den im Content-Type gegebenen Typ verwendet.

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-Politik-Datei (crossdomain.xml) erlaubt ist. Die Datei kann eine Politik definieren, um Clients, wie den mittlerweile veralteten Adobe Flash Player, Adobe Acrobat, Microsoft Silverlight (ebenfalls veraltet) oder Apache Flex, die Erlaubnis zu erteilen, mit Daten über Domänen hinweg umzugehen, die andernfalls aufgrund der Same-Origin-Policy eingeschränkt wären. Weitere Informationen finden Sie in der Cross-domain Policy File Specification.

X-Powered-By

Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, während sie der Anwendung oder ihren Besuchern keinen Nutzen bieten. Entfernen Sie diesen Header, um potenzielle Schwachstellen zu verbergen.

X-XSS-Protection

Aktiviert die Filterung für Cross-Site-Scripting.

Fetch-Metadaten-Anforderungsheader

Fetch-Metadaten-Anforderungsheader liefern Informationen über den Kontext, aus dem eine Anfrage stammt. Ein Server kann sie verwenden, um Entscheidungen darüber zu treffen, ob eine Anfrage basierend auf ihrer Herkunft und der Art, wie die Ressource genutzt wird, erlaubt werden soll.

Sec-Fetch-Site

Gibt die Beziehung zwischen dem Ursprung eines Anforderungsinitiators und dem Ursprung seines Ziels 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 handelt sich um einen strukturierten 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, daher sind mögliche Werte ?0 für false und ?1 für true.

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 "Fetch-Metadaten-Anforderungsheader", liefern jedoch ähnliche Informationen über den Kontext, wie eine Ressource genutzt werden soll. Ein Server könnte sie verwenden, um sein Caching-Verhalten zu ändern oder die bereitgestellten Informationen:

Sec-Purpose

Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes ist als die unmittelbare Verwendung durch den Benutzeragenten. Der Header hat derzeit einen möglichen Wert, prefetch, was darauf hinweist, dass die Ressource vorab für eine mögliche zukünftige Navigation abgerufen wird.

Service-Worker-Navigation-Preload

Ein Anforderungsheader, der in einer vorab gesendeten Anfrage geschickt wird, um eine Ressource während des Starts eines Service Workers mit fetch() abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource zurückgegeben werden sollte als in einer normalen fetch()-Operation.

Server-gesendete Ereignisse

Reporting-Endpoints

Antwortheader, der verwendet wird, um Server-Endpunkte anzugeben, wohin der Browser Warnungen und Fehlerberichte senden soll, wenn die Reporting API verwendet wird.

Report-To Veraltet Nicht standardisiert

Antwortheader, der verwendet wird, um Server-Endpunkte anzugeben, wohin der Browser Warnungen und Fehlerberichte senden soll, wenn die Reporting API verwendet wird.

Transfer-Codierung

Transfer-Encoding

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

TE

Gibt die Transfer-Codierungen an, die der Benutzeragent akzeptieren möchte.

Trailer

Ermöglicht es dem Absender, zusätzliche Felder am Ende einer chunked Nachricht hinzuzufügen.

WebSockets

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

Sec-WebSocket-Accept

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

Sec-WebSocket-Extensions

In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten WebSocket-Erweiterungen an. In Antworten gibt 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 eine WebSocket-Verbindung öffnen möchte.

Sec-WebSocket-Protocol

In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten Sub-Protokolle an. In Antworten gibt er 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 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 Wege zur Erreichung dieses Dienstes aufzulisten.

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, ein oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML-<link>-Element.

Retry-After

Gibt an, wie lange der Benutzeragent warten soll, bevor er eine Nachfolgestellung machen soll.

Server-Timing

Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anforderungs-Antwort-Zyklus.

Service-Worker-Allowed

Wird verwendet, um die Pfadeinschränkung zu entfernen, indem dieser Header in der Antwort des Service Worker-Skripts enthalten ist.

SourceMap

Verknüpft generierten Code mit einer Quellkarte.

Upgrade

Dieser HTTP/1.1- (nur) Header kann verwendet werden, um eine bereits bestehende Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) aufzurüsten. Beispielsweise kann ein Client eine Verbindung von HTTP 1.1 auf HTTP 2.0 aufrüsten oder eine HTTP- bzw. HTTPS-Verbindung in einen WebSocket umwandeln.

Priority

Liefert einen Hinweis auf die Priorität einer bestimmten Ressourcenanforderung bei einer bestimmten Verbindung. Der Wert kann in einer Anforderung gesendet werden, um die Clientpriorität anzuzeigen, oder in einer Antwort, wenn der Server beschließt, die Anfrage neu zu priorisieren.

Experimentelle Header

Zuordnungsbericht-Header

Die Attribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen – zum Beispiel, wenn ein Benutzer auf eine auf einer Seite eingebettete Anzeige klickt und dann den Artikel auf der Website des Anbieters kauft – und dann Berichte über diese Konversionen zu erstellen. Dies geschieht ohne den Rückgriff auf Drittanbieter-Cookies, indem verschiedene Header verwendet werden, um Quellen und Trigger zu registrieren, die einen Konversion anzeigen.

Attribution-Reporting-Eligible

Wird verwendet, um anzugeben, dass die Antwort auf die aktuelle Anfrage berechtigt ist, an der Berichterstellung für Attributionen teilzunehmen, indem entweder eine Attributionsquelle oder ein Trigger registriert wird.

Attribution-Reporting-Register-Source

Wird als Teil einer Antwort auf eine Anfrage mit einem Attribution-Reporting-Eligible-Header eingeschlossen und dient zur Registrierung einer Attributionsquelle.

Attribution-Reporting-Register-Trigger

Wird als Teil einer Antwort auf eine Anfrage mit einem Attribution-Reporting-Eligible-Header eingeschlossen und dient zur Registrierung eines Attributionstriggers.

Client-Hinweise

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

Server fordern proaktiv die Client-Hints-Header an, an denen sie vom Client interessiert sind, indem sie Accept-CH verwenden. Der Client kann dann entscheiden, ob er die angeforderten Header in nachfolgenden Anfragen einschließt.

Accept-CH

Server können die Unterstützung für Client-Hints über das Accept-CH-Header-Feld oder ein äquivalentes HTML <meta>-Element mit der http-equiv-Eigenschaft ankündigen.

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 aufgelistet.

Benutzeragent-Client-Hints

Die UA-Client-Hints sind Anforderungsheader, die Informationen über den Benutzeragenten, die Plattform/Architektur, auf der er läuft, und von dem Benutzeragenten oder der Plattform festgelegte Benutzerpräferenzen bereitstellen:

Sec-CH-UA Experimentell

Marke und Version des Benutzeragenten.

Sec-CH-UA-Arch Experimentell

Unterliegende Plattformarchitektur des Benutzeragenten.

Sec-CH-UA-Bitness Experimentell

Architektur-Bitness der unterliegenden CPU des Benutzeragenten (zum Beispiel "64" Bit).

Sec-CH-UA-Form-Factor Experimentell

Formfaktoren des Benutzeragenten, die beschreiben, wie der Benutzer mit dem Benutzeragenten interagiert.

Sec-CH-UA-Full-Version Veraltet

Vollständige Versionszeichenfolge des Benutzeragenten.

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

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

Sec-CH-UA-Mobile Experimentell

Benutzeragent läuft auf einem mobilen Gerät oder bevorzugt im Allgemeinen eine "mobile" Benutzererfahrung.

Sec-CH-UA-Model Experimentell

Gerätemodell des Benutzeragenten.

Sec-CH-UA-Platform Experimentell

Unterliegendes Betriebssystem/Plattform des Benutzeragenten.

Sec-CH-UA-Platform-Version Experimentell

Version des unterliegenden Betriebssystems des Benutzeragenten.

Sec-CH-UA-WoW64 Experimentell

Zeigt an, ob die Benutzeragenten-Binärdatei im 32-Bit-Modus auf einem 64-Bit-Windows läuft.

Sec-CH-Prefers-Color-Scheme Experimentell

Benutzerpräferenz für dunkles oder helles Farbthema.

Sec-CH-Prefers-Reduced-Motion Experimentell

Benutzerpräferenz, weniger Animationen und Inhaltslayoutverschiebungen zu sehen.

Sec-CH-Prefers-Reduced-Transparency Experimentell

Anforderungsheader, der die Präferenz des Benutzeragenten für reduzierte Transparenz angibt.

Hinweis: Benutzeragent-Client-Hints sind nicht in geschützten Frames verfügbar, da sie auf der Delegation der Berechtigungsrichtlinie basieren, welche zum Datenleck genutzt werden könnte.

Geräte-Client-Hints

Content-DPR Veraltet Nicht standardisiert

Antwortheader, der das Gerätebild zum Pixelverhältnis (DPR) in Anfragen bestätigt, bei denen der Bildschirm-DPR-Client-Hint verwendet wurde, um eine Bildressource 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 Geräte-Pixelverhältnis des Clients bereitstellt (die Anzahl der physischen Geräte-Pixel für jedes CSS-Pixel).

Viewport-Width Veraltet Nicht standardisiert

Anforderungsheader, der die Layout-Viewport-Breite des Clients in CSS-Pixeln bereitstellt.

Width Veraltet Nicht standardisiert

Anforderungsheader, der die gewünschte Ressourcenbreite in physischen Pixeln anzeigt (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise erlauben einem Server, auszuwählen, welche Informationen basierend auf Benutzerpräferenzen und Netzwerkbandbreite und -latenz gesendet werden.

Ungefähre Bandbreite der Verbindung des Clients zum Server in Mbps. Dies ist Teil der Network Information API.

ECT Experimentell

Der effektive Verbindungstyp ("Netzwerkprofil"), das 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, einschließlich der Serververarbeitungszeit. Dies ist Teil der Network Information API.

Save-Data Experimentell

Ein String on, der die Präferenz des Benutzeragenten für reduzierten Datenverbrauch anzeigt.

Datenschutz

DNT Veraltet Nicht standardisiert

Anforderungsheader, der die Tracking-Präferenz des Benutzers (Nicht verfolgen) anzeigt. Abgeschafft zugunsten von Global Privacy Control (GPC), welches Server mittels Sec-GPC-Header mitgeteilt wird und für Clients über navigator.globalPrivacyControl zugänglich ist.

Tk Veraltet Nicht standardisiert

Antwortheader, der den Tracking-Status angibt, der auf die entsprechende Anfrage angewendet wurde. In Verbindung mit DNT verwendet.

Sec-GPC Nicht standardisiert Experimentell

Gibt an, ob der Benutzer der Verkauf oder das Teilen seiner persönlichen Informationen mit Dritten durch eine Website oder einen Dienst zustimmt.

Sicherheit

Origin-Isolation Experimentell

Bietet einen Mechanismus, der es Webanwendungen ermöglicht, ihre Ursprünge zu isolieren.

Server-gesendete Ereignisse

NEL Experimentell

Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Berichtspolitik für Netzwerkfehler zu deklarieren.

Topics API

Die Topics API bietet einen Mechanismus für Entwickler, Use Cases 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 markieren, die aus der URL einer aufrufenden Seite abgeleitet wurden, wenn sie auf die Antwort einer durch eine Funktion, die die Topics API ermöglicht, generierten Anfrage beobachtet wird.

Sec-Browsing-Topics Experimentell Nicht standardisiert

Anforderungsheader, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anforderung sendet, welche von einer Ad-Tech-Plattform verwendet werden, 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 anzugeben, potenziell verfügbare Signaturen zu nutzen, sowie um die unterstützten Arten von Signaturen zu kennzeichnen.

Early-Data Experimentell

Gibt an, dass die Anfrage in TLS Early Data übermittelt wurde.

Origin-Agent-Cluster Experimentell

Antwortheader, der verwendet wird, um anzugeben, dass das zugeordnete Document in einem ursprungsbezogenen Agent-Cluster platziert werden soll. Diese Isolierung ermöglicht es Benutzeragenten, implementierungsspezifische Ressourcen für Agent-Cluster, wie Prozesse oder Threads, effizienter zuzuweisen.

Set-Login Experimentell

Antwortheader, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Login-Status zu setzen, d.h., ob Benutzer derzeit in dem IdP auf dem aktuellen Browser eingeloggt sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM API verwendet.

Signature Experimentell

Das Signature Headerfeld übermittelt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität dieser Signatur bestimmt und aktualisiert werden kann.

Signed-Headers Experimentell

Das Signed-Headers Headerfeld identifiziert eine geordnete Liste von Antwortheaderfeldern, die in eine Signatur eingeschlossen werden sollen.

Speculation-Rules Experimentell

Stellt eine Liste von URLs bereit, die auf textuelle Ressourcen verweisen, die Definitionsdateien für Speculation Rules JSON enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Speculation Rule-Set des Dokuments hinzugefügt.

Supports-Loading-Mode Experimentell

Wird von einem Navigationstarget gesetzt, um die Nutzung verschiedener riskanterer Lade-Modi zu ermöglichen. Zum Beispiel erfordert die Verwendung 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 sich über einen HTTP-Proxy oder einen Load-Balancer mit einem Webserver verbindet.

X-Forwarded-Host Nicht standardisiert

Identifiziert den ursprünglichen Host, der bei einer Verbindung durch den Client zu Ihrem Proxy oder Load-Balancer angefordert wurde.

X-Forwarded-Proto Nicht standardisiert

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

X-DNS-Prefetch-Control Nicht standardisiert

Kontrolliert das DNS-Prefetching, eine Funktion, bei der Browser proaktiv die Domainnamenauflösung für Links durchführen, denen der Benutzer möglicherweise folgt, sowie für URLs von Dokument-Referenzen wie Bilder, CSS, JavaScript usw.

X-Robots-Tag Nicht standardisiert

Der X-Robots-Tag HTTP-Header wird verwendet, um anzuzeigen, wie eine Webseite innerhalb der öffentlichen Suchmaschinenergebnisse indexiert werden soll. Der Header ist effektiv gleichwertig mit <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet

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

Warning Veraltet

Allgemeine Warninformationen zu möglichen Problemen.

Mitwirken

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

Siehe auch