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.
No-Vary-Search Experimentell: 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

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

CORS

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.
Link: 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.

Downlink Experimentell: Ungefähre Bandbreite der Verbindung des Clients zum Server in Mbps. Dies ist Teil der Network Information API.
ECT Experimentell: Der effektive Verbindungstyp ("Netzwerkprofil"), 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.