HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort zu übermitteln. In HTTP/1.X ist ein Header ein nicht fallunterscheidender Name, 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 in Kleinbuchstaben angezeigt, wenn sie in Entwicklerwerkzeugen betrachtet werden (accept: */*), und für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt vorangestellt (:status: 200). Sie finden weitere Informationen zur Syntax in jeder Protokollversion 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 sie verursachte, wenn nicht standardisierte Felder standardisiert wurden, in RFC 6648 abgeschafft; andere sind im IANA HTTP Feldnamenregister aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status.

Header können entsprechend ihrem Kontext gruppiert werden:

Request-Header: Enthalten zusätzliche Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.
Response-Header: Enthalten zusätzliche Informationen über die Antwort, wie ihren Standort oder Informationen über den Server, der sie bereitstellt.
Darstellungs-Header: Enthalten Informationen über den Hauptteil der Ressource, wie ihren MIME-Typ oder die angewandte Kodierung/Komprimierung.
Nutzdaten-Header: Enthalten darstellungsunabhängige Informationen über Nutzdaten, einschließlich Inhaltslänge und der für den Transport verwendeten Kodierung.

Header können auch entsprechend ihrer Behandlung durch Proxies gruppiert werden:

End-to-end-Header: Diese Header müssen an den endgültigen Empfänger der Nachricht übermittelt werden: den Server bei einer Anfrage oder den Client bei einer Antwort. Zwischenproxies müssen diese Header unverändert weiterleiten und in Caches speichern.
Hop-by-hop-Header: Diese Header sind nur für eine einzelne Transportverbindung von Bedeutung und dürfen nicht von Proxies weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mithilfe des Connection-Headers gesetzt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden soll.
Authorization: Enthält die Anmeldeinformationen zur Authentifizierung eines User-Agent bei einem Server.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden soll.
Proxy-Authorization: Enthält die Anmeldeinformationen zur Authentifizierung eines User-Agent bei einem Proxy-Server.

Caching

Age: Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache gespeichert ist.
Cache-Control: Direktiven für Cache-Mechanismen in sowohl Anfragen als auch Antworten.
Clear-Site-Data: Löscht Browsing-Daten (z. B. Cookies, Speicher, Cache), die mit der anfragenden Website verbunden sind.
Expires: Das Datum/Uhrzeit nach dem die Antwort als veraltet angesehen wird.
No-Vary-Search Experimentell: Gibt einen Satz von Regeln an, die definieren, wie die Abfrageparameter einer URL das Cache-Matching beeinflussen. Diese Regeln legen fest, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Einträge im Browser-Cache gespeichert werden soll.

Bedingte Anfragen

Last-Modified: Das Datum der letzten Änderung der Ressource, das verwendet wird, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau als ETag, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anfragen mit If-Modified-Since und If-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.
ETag: Ein eindeutiger String, der 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 mit keinem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen) oder 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 stellt die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen sicher oder dient dazu, ein optimistisches Nebenläufigkeitssteuerungssystem bei der Änderung bestehender Dokumente zu implementieren.
Vary: Bestimmt, wie Anforderungsheader abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom ursprünglichen Server anzufordern.

Verbindungsmanagement

Connection: Steuert, ob die Netzwerkverbindung geöffnet bleibt, nachdem die aktuelle Transaktion abgeschlossen ist.
Keep-Alive: Steuert, wie lange eine persistente Verbindung offen bleiben soll.

Inhaltsaushandlung

Weitere Details finden Sie im Artikel Inhaltsaushandlung.

Accept: Informiert den Server über die Typen von Daten, die zurückgesendet werden können.
Accept-Encoding: Der Kodierungsalgorithmus, normalerweise ein Komprimierungsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.
Accept-Language: Informiert den Server über die menschliche Sprache, die der Server zurücksenden soll. Dies ist ein Hinweis und liegt nicht unbedingt vollständig unter der Kontrolle des Benutzers: der Server sollte immer darauf achten, eine explizite Benutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.
Accept-Patch: Ein Antwort-Header zur Inhaltsaushandlung einer Anfrage, der angibt, welche Medientype der Server in einer PATCH-Anfrage verstehen kann.
Accept-Post: Ein Antwort-Header zur Inhaltsaushandlung einer Anfrage, der angibt, welche Medientype der Server in einer POST-Anfrage verstehen kann.

Kontrollen

Expect: Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.
Max-Forwards: Wenn TRACE verwendet wird, gibt an, wie viele Übergabe die Anfrage durchführen kann, bevor sie an den 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 User-Agent.

CORS

Weitere Informationen finden Sie in der CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage angezeigt werden kann, wenn das Anmeldeinformationsflag wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header bei der Erstellung 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 gemeinsam genutzt werden kann.
Access-Control-Expose-Headers: Gibt an, welche Header als Teil der Antwort angezeigt 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 beim Senden einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header bei der Erstellung der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird beim Senden einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode bei der Erstellung 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 einzusehen, die über Funktionen der Resource Timing API abgerufen werden, welche aufgrund von Cross-Origin-Beschränkungen sonst als Null gemeldet würden.

Downloads

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

Integritätsprüfsummen

Content-Digest Experimentell: Stellt eine Prüfsumme des Streams von Oktett-Rahmen in einer HTTP-Nachricht (des Nachrichteninhalts) abhängig von Content-Encoding und Content-Range bereit.
Repr-Digest Experimentell: Bietet eine Prüfsumme der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zur Content-Digest berücksichtigt die Prüfsumme nicht Content-Encoding oder Content-Range.
Want-Content-Digest Experimentell: Gibt den Wunsch nach einem Content-Digest-Header an. Es ist das Content--Äquivalent von Want-Repr-Digest.
Want-Repr-Digest Experimentell: Gibt den Wunsch nach einem Repr-Digest-Header an. Es ist das Repr--Äquivalent von Want-Content-Digest.

Informationen zum Nachrichtenkörper

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 Komprimierungsalgorithmus anzugeben.
Content-Language: Beschreibt die zur Zielgruppe passenden menschlichen Sprache(n), sodass es einem Benutzer ermöglicht wird, nach seinen eigenen bevorzugten Spracheinstellungen zu unterscheiden.
Content-Location: Gibt einen alternativen Speicherort 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 Anforderungspfad beteiligt ist.
Via: Wird von Proxies, sowohl Vor- als auch Rückwärtsproxies, hinzugefügt und kann in den Anforderungs- und Antwort-Headern erscheinen.

Bereichsanfragen

HTTP-Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Medienplayer, die zufälligen Zugriff unterstützen, Datentools, die wissen, dass sie 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, wenn ja, in welcher Einheit der Bereich ausgedrückt werden kann.
Range: Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.
If-Range: Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn das angegebene ETag oder Datum mit der entfernten Ressource übereinstimmt. Verhindert das Herunterladen von zwei Bereichen einer inkompatiblen Version der Ressource.
Content-Range: Gibt an, zu welcher Position in einer vollständigen Nachricht eine Teilnachricht gehört.

Weiterleitungen

Location: Gibt die URL an, zu der eine Seite umgeleitet werden soll.
Refresh: Veranlasst den Browser, die Seite neu zu laden oder zu einer anderen Seite weiterzuleiten. Nimmt denselben Wert wie das meta-Element mit http-equiv="refresh".

Anforderungskontext

From: Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der die anfragende User-Agent steuert.
Host: Gibt den Domänennamen des Servers (für das virtuelle Hosting) und optional die TCP-Portnummer an, auf der der Server lauscht.
Referer: Die Adresse der vorherigen Webseite, von der 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 Netzwerkprotokollpartnern ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwarehersteller oder die Softwareversion der anfragenden Software zu identifizieren.

Antwortkontext

Allow: Listet die HTTP-Anfragemethoden auf, die von einer Ressource unterstützt werden.
Server: Enthält Informationen über die Software, die vom Ursprungsserver zur Bearbeitung der Anfrage verwendet wird.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht einem Server, eine Einbettungsrichtlinie für ein bestimmtes Dokument festzulegen.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domains ein Fenster öffnen oder steuern.
Cross-Origin-Resource-Policy (CORP): Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch den CORP-Artikel.
Content-Security-Policy (CSP): Kontrolliert, welche Ressourcen der User-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Ermöglicht es Webentwicklern, mit Richtlinien zu experimentieren, indem sie deren Auswirkungen überwachen, aber nicht durchsetzen lassen. Diese Verstöße bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.
Expect-CT Veraltet: Ermöglicht es Websites, sich in die Berichterstattung und Durchsetzung von Certificate Transparency einzuklinken, um den Einsatz von falsch ausgestellten Zertifikaten für diese Website zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Verwendung von Browserfunktionen in einem eigenen Frame einer Website sowie in darin eingebetteten <iframe>s zu erlauben und zu verweigern.
Reporting-Endpoints Experimentell: Antwort-Header, der Website-Besitzern erlaubt, ein oder mehrere Endpunkte festzulegen, die verwendet werden, um Fehler wie CSP-Verletzungsberichte, Cross-Origin-Opener-Policy-Berichte oder andere allgemeine Verstöße zu erhalten.
Strict-Transport-Security (HSTS): Erzwingt die Kommunikation über HTTPS anstelle von HTTP.
Upgrade-Insecure-Requests: Sendet ein Signal an den Server, das die Vorliebe des Clients für eine verschlüsselte und authentifizierte Antwort und seine Fähigkeit zur erfolgreichen Handhabung der upgrade-insecure-requests-Direktive ausdrückt.
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 anderen), die Erlaubnis geben, 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 trotzdem unerwünschte Anfragen blockieren.
X-Powered-By: Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, während es für die Anwendung oder deren Besucher keinen Nutzen bietet. Deaktivieren Sie diesen Header, um potenzielle Sicherheitslücken nicht offenzulegen.
X-XSS-Protection: Aktiviert die Filterung von Cross-Site-Scripting-Angriffen.

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 sein sollte, basierend darauf, woher sie kam und wie die Ressource verwendet werden wird.

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprung eines Anforderungsinitiators und dem Zielursprung an. Es ist ein strukturierter Header, dessen Wert ein Token mit möglichen Werten cross-site, same-origin, same-site und none ist.
Sec-Fetch-Mode: Gibt den Modus der Anfrage an einen Server an. Es ist ein strukturierter Header, dessen Wert ein Token mit möglichen Werten cors, navigate, no-cors, same-origin und websocket ist.
Sec-Fetch-User: Gibt an, ob eine Navigationsanfrage durch Benutzeraktivierung ausgelöst wurde oder nicht. Es ist ein strukturierter Header, dessen Wert ein boolescher Wert ist, sodass mögliche Werte ?0 für false und ?1 für true sind.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es ist ein strukturierter 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 der Verwendung einer Ressource. Ein Server könnte sie verwenden, um sein Caching-Verhalten oder die bereitgestellten Informationen zu ändern:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als die sofortige Verwendung durch den User-Agent ist. Der Header hat derzeit einen möglichen Wert, prefetch, der angibt, dass die Ressource präventiv für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungsheader, der in einer vorausgreifenden Anfrage gesendet wird, um mit fetch() eine Ressource während des Service-Worker-Boots abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einem Server mitzuteilen, dass eine andere Ressource als in einer normalen fetch()-Operation zurückgegeben werden soll.

Server-gesendete Ereignisse

Reporting-Endpoints: Antwortheader, der verwendet wird, um Serverendpunkte zu spezifizieren, an die der Browser Warn- und Fehlermeldungen senden soll, wenn die Reporting API verwendet wird.
Report-To Veraltet Nicht standardisiert: Antwortheader, der verwendet wird, um Serverendpunkte zu spezifizieren, an die der Browser Warn- und Fehlermeldungen senden soll, wenn die Reporting API verwendet wird.

Transfer-Codierung

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 zu akzeptieren bereit ist.
Trailer: Ermöglicht es dem Absender, zusätzliche Felder am Ende einer chunked-Nachricht einzuschließen.

WebSockets

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

Sec-WebSocket-Accept: Antwort-Header, der anzeigt, dass der Server bereit ist, eine WebSocket-Verbindung herzustellen.
Sec-WebSocket-Extensions: In Anfragen gibt dieser Header an, welche WebSocket-Erweiterungen vom Client in bevorzugter Reihenfolge unterstützt werden. In Antworten gibt er die vom Server aus den Präferenzen des Clients ausgewählte Erweiterung an.
Sec-WebSocket-Key: Anforderungs-Header, der einen Schlüssel enthält, der überprüft, dass der Client explizit beabsichtigt, eine WebSocket zu eröffnen.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die in bevorzugter Reihenfolge unterstützten Sub-Protokolle des Clients 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 genutzte WebSocket-Protokollversion 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 aufzulisten, diesen Dienst zu erreichen.
Alt-Used: Wird verwendet, um den alternativen Dienst zu identifizieren, der verwendet wird.
Date: Enthält das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde.
Link: Diese Entität-Header-Feld bietet eine Möglichkeit zum Serialisieren von einem oder mehreren Links in HTTP-Headern. Es ist semantisch äquivalent zum HTML <link>-Element.
Retry-After: Gibt an, wie lange der User-Agent warten soll, bevor er eine Folgeanfrage stellt.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.
Service-Worker: Wird in Abfragen für den Skript-Ressource eines Service-Workers aufgenommen. Dieser Header hilft Administratoren dabei, Anfragen von Service-Worker-Skripten zu protokollieren.
Service-Worker-Allowed: Wird verwendet, um die Pfadeinschränkung zu entfernen, indem dieser Header in der Antwort des Service-Worker-Skripts enthalten ist.
SourceMap: Verweist auf eine Quellenkarte, damit Debugger durch den ursprünglichen Quellcode anstelle von generiertem oder transformiertem Code gehen können.
Upgrade: Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits bestehende Client/Server-Verbindung zu einem anderen Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Zum Beispiel kann es von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- oder HTTPS-Verbindung in eine WebSocket-Verbindung aufzurüsten.
Priority: Bietet einen Hinweis auf die Priorität einer bestimmten Ressourcenanforderung bei einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzugeben, oder in einer Antwort, wenn der Server sich entscheidet, die Anfrage zu repriorisieren.

Experimentelle Header

Kopfzeilen zur Attributionsberichterstattung

Die Attributionsberichterstattungs-API ermöglicht es Entwicklern, Konversionen zu messen - zum Beispiel, wenn ein Nutzer auf eine Anzeige klickt, die auf einer Seite eingebettet ist, und dann auf der Seite des Anbieters das Produkt kauft - und Berichte über diese Konversionen abzurufen. Dies geschieht ohne Verwendung von Drittanbieter-Tracking-Cookies, sondern durch die Verwendung verschiedener Header, um Quellen und Trigger zu registrieren, die zur Angabe einer Konversion zugeordnet sind.

Attribution-Reporting-Eligible: Wird verwendet, um anzugeben, dass die Antwort auf die aktuelle Anfrage berechtigt ist, an der Attributionsberichterstattung teilzunehmen, indem entweder eine Attributionsquelle oder ein Trigger registriert wird.
Attribution-Reporting-Register-Source: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, verwendet, um eine Attributionsquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, verwendet, um einen Attributionstrigger zu registrieren.

Client-Hinweise

HTTP-Client-Hinweise sind eine Reihe von Anforderungsheadern, die nützliche Informationen über den Client wie Gerätetyp und Netzbedingungen bereitstellen und es den Servern ermöglichen, das, was unter diesen Bedingungen serviert wird, zu optimieren.

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

Accept-CH: Server können Unterstützung für Client-Hinweise über das Feld Accept-CH im Header oder ein entsprechendes HTML-<meta>-Element mit http-equiv-Attribut bewerben.
Critical-CH Experimentell: Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client-Hinweise auch kritische Client-Hinweise sind.

Die verschiedenen Kategorien von Client-Hinweisen sind unten aufgelistet.

User-Agent-Client-Hinweise

Die User-Agent-Client-Hinweise sind Anforderungsheader, die Informationen über den User-Agent, die Plattform/Architektur, auf der er läuft, und die vom User-Agent oder der Plattform festgelegten Benutzereinstellungen bieten:

Sec-CH-UA Experimentell: Marken- und Versionsangaben des User-Agent.
Sec-CH-UA-Arch Experimentell: Plattformarchitektur des User-Agent.
Sec-CH-UA-Bitness Experimentell: CPU-Architekturbissigkeit des User-Agent (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factors Experimentell: Formfaktoren des User-Agent, die beschreiben, wie der Benutzer mit dem User-Agent interagiert.
Sec-CH-UA-Full-Version Veraltet: Vollständige Versionszeichenkette des User-Agent.
Sec-CH-UA-Full-Version-List Experimentell: Vollversion für jede Marke in der Markenliste des User-Agent.
Sec-CH-UA-Mobile Experimentell: Der User-Agent läuft auf einem Mobilgerät oder bevorzugt generell ein "mobiles" Nutzererlebnis.
Sec-CH-UA-Model Experimentell: Gerätemodell des User-Agent.
Sec-CH-UA-Platform Experimentell: Betriebssystem/Plattform des User-Agent.
Sec-CH-UA-Platform-Version Experimentell: Betriebssystemversion des User-Agent.
Sec-CH-UA-WoW64 Experimentell: Ob das User-Agent-Binary im 32-Bit-Modus auf 64-Bit-Windows läuft oder nicht.
Sec-CH-Prefers-Color-Scheme Experimentell: Nutzerpräferenz für dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion Experimentell: Nutzerpräferenz, weniger Animationen und Inhaltebewegungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anforderungsheader, der die Präferenz des User-Agent für reduzierte Transparenz angibt.

Hinweis: User-Agent-Client-Hinweise sind innerhalb von fenced frames nicht verfügbar, da sie auf Berechtigungsrichtlinien-Delegation beruhen, die verwendet werden könnten, um Daten zu leaken.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert: Antwort-Header, mit dem das Bildgerät-zu-Pixel-Verhältnis (DPR) in Anfragen bestätigt wird, bei denen der Bildschirm DPR-Client-Hinweis verwendet wurde, um eine Bildressource auszuwählen.
Device-Memory: Ungefähre Menge des verfügbaren RAM-Speichers des Clients. Dies ist Teil der Gerätespeicher-API.
DPR Veraltet Nicht standardisiert: Anforderungsheader, der das Pixelverhältnis des Client-Geräts (die Anzahl physischer Gerätepixel pro CSS-Pixel) bereitstellt.
Viewport-Width Veraltet Nicht standardisiert: Anforderungsheader bietet die Breite des Layout-Viewports des Clients in CSS-Pixeln.
Width Veraltet Nicht standardisiert: Anforderungsheader gibt die gewünschte Ressourcenbreite in physischen Pixeln an (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hinweise

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

Downlink Experimentell: Ungefähre Bandbreite der Verbindung des Clients zum Server, in Mbps. Dies ist Teil der Netzwerkinformations-API.
ECT Experimentell: Der effektive Verbindungstyp ("Netzwerkprofil"), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Netzwerkinformations-API.
RTT Experimentell: Anwendungsschicht-Round-Trip-Zeit (RTT) in Millisekunden, einschließlich der Serververarbeitungszeit. Dies ist Teil der Netzwerkinformations-API.
Save-Data Experimentell: Ein String on, der die Präferenz des User-Agent für eine reduzierte Datennutzung angibt.

Datenschutz

DNT Veraltet Nicht standardisiert: Anforderungsheader, der die Nachverfolgungspräferenz des Nutzers (Do Not Track) angibt. Veraltet zugunsten der Global Privacy Control (GPC), die als Sec-GPC-Header an Server übermittelt wird und auf die über navigator.globalPrivacyControl von Clients zugegriffen werden kann.
Tk Veraltet Nicht standardisiert: Antwortheader, der den Tracking-Status angibt, der auf die entsprechende Anfrage angewandt wurde. Wird in Verbindung mit DNT verwendet.
Sec-GPC Nicht standardisiert Experimentell: Gibt an, ob der Nutzer damit einverstanden ist, dass eine Website oder ein Dienst seine persönlichen Informationen mit Dritten verkauft oder teilt.

Sicherheit

Origin-Agent-Cluster Experimentell: Antwortheader, der angibt, dass das zugehörige Dokument in ein Ursprung-zugeordnetes Agent-Cluster platziert werden sollte. Diese Isolation ermöglicht es Benutzeragenten, agentenspezifische Ressourcen, wie Prozesse oder Threads, effizienter zuzuweisen.

Server-gesendete Ereignisse

NEL Experimentell: Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Netzwerkfehlerberichtungsrichtlinie zu deklarieren.

Themen-API

Die Themen-API bietet Entwicklern einen Mechanismus, um Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. Siehe die Themen-API-Dokumentation für weitere Informationen.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwortheader, der verwendet wird, um Themen von Interesse zu markieren, die aus der URL der anrufenden Seite abgeleitet werden, wie sie in der Antwort auf eine Anfrage eines Features, das die Themen-API aktiviert beobachtet wurden.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Anforderungsheader, der die ausgewählten Themen für den aktuellen Nutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Ad-Tech-Plattform verwendet werden, um eine personalisierte Anzeige zu wählen, die angezeigt werden soll.

Andere

Accept-Signature Experimentell: Ein Client kann das Accept-Signature-Header-Feld senden, um die Absicht anzuzeigen, verfügbare Signaturen zu nutzen und anzugeben, welche Arten von Signaturen er unterstützt.
Early-Data Experimentell: Gibt an, dass die Anfrage in TLS Early-Data übertragen wurde.
Set-Login Experimentell: Antwortheader, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, 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: Das Signature-Header-Feld enthält eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität dieser Signatur bestimmt und diese erfrischt werden kann.
Signed-Headers Experimentell: Das Signed-Headers-Header-Feld identifiziert eine geordnete Liste von Antwortheaderfeldern zur Aufnahme in eine Signatur.
Speculation-Rules Experimentell: Bietet eine Liste von URLs zu Textressourcen, die Spekulationsregel-JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregelsatz des Dokuments hinzugefügt.
Supports-Loading-Mode Experimentell: Wird von einem Navigationstarget gesetzt, um eine Opt-in-Erlaubnis für die Verwendung verschiedener höher-riskanter Lade-Modi zu geben. Zum Beispiel erfordert grenzübergreifendes, ähnliches Prerendering einen Supports-Loading-Mode-Wert von credentialed-prerender.

Nicht-standardisierte Header

X-Forwarded-For Nicht standardisiert: Identifiziert die ursprungstechnischen 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ünglich angeforderten Host, den ein Client zum Verbinden mit Ihrem Proxy oder Load-Balancer verwendet hat.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet, um sich mit Ihrem Proxy oder Load-Balancer zu verbinden.
X-DNS-Prefetch-Control Nicht standardisiert: Kontrolliert das DNS-Vorabrufen, eine Funktion, durch die Browser proaktiv die Domänennamenauflösung für beide Links durchführen, die der Benutzer möglicherweise verfolgt, sowie für URLs von Elementen, die im Dokument referenziert sind, einschließlich Bildern, CSS, JavaScript usw.
X-Robots-Tag Nicht standardisiert: Der X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite in den Ergebnissen öffentlicher Suchmaschinen indiziert werden soll. Der Header ist im Wesentlichen äquivalent zum <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet: Implementierungsspezifischer Header, der überall entlang der Anfrage-Antwort-Kette verschiedene Effekte haben kann. Wird für die Rückwärtskompatibilität mit HTTP/1.0-Caches verwendet, bei denen der Cache-Control-Header noch nicht vorhanden ist.
Warning Veraltet: Allgemeine Warninformationen über mögliche Probleme.

Beteiligung

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