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-anfälliger Name, gefolgt von einem Doppelpunkt, dann optionalen Leerzeichen, die ignoriert werden, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header in Kleinbuchstaben angezeigt, wenn sie in Entwickler-Tools betrachtet werden (accept: */*), und mit einem Doppelpunkt für eine spezielle Gruppe von Pseudo-Headern versehen (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.

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

Header können entsprechend ihrer Kontexte gruppiert werden:

Request-Header: Enthalten mehr Informationen über die abzurufende Ressource oder den Client, der die Ressource anfordert.
Response-Header: Enthalten zusätzliche Informationen über die Antwort, wie deren Standort oder den Server, der sie bereitstellt.
Repräsentations-Header: Enthalten Informationen über den Körper der Ressource, wie deren MIME-Typ oder die angewandte Kodierung/Kompression.
Payload-Header: Enthalten darstellungsunabhängige Informationen über Payload-Daten, 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 zum endgültigen Empfänger der Nachricht übertragen werden: der Server für eine Anfrage oder der Client für eine Antwort. Zwischenproxies müssen diese Header unverändert weiterleiten und Caches müssen sie speichern.
Hop-by-hop-Header: Diese Header sind nur für eine einzelne Transportebene sinnvoll und dürfen nicht von Proxies weitergeleitet oder gespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mit dem Connection-Header gesetzt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource zuzugreifen.
Authorization: Enthält die Anmeldeinformationen, um einen Benutzer-Agenten bei einem Server zu authentifizieren.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource hinter einem Proxy-Server zuzugreifen.
Proxy-Authorization: Enthält die Anmeldeinformationen, um einen Benutzer-Agenten bei einem Proxy-Server zu authentifizieren.

Cache

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

Bedingte Anfragen

Last-Modified: Das Datum der letzten Änderung der Ressource, das verwendet wird, um verschiedene Versionen derselben Ressource zu vergleichen. Es ist weniger genau als ETag, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anfragen, die If-Modified-Since und If-Unmodified-Since verwenden, nutzen diesen Wert, um das Verhalten der Anfrage zu ändern.
ETag: Ein einzigartiger String, der die Version der Ressource identifiziert. Bedingte Anfragen, die If-Match und If-None-Match verwenden, nutzen 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 keinen der angegebenen ETags entspricht. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen) oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine vorhanden ist.
If-Modified-Since: Macht die Anfrage bedingt und erwartet, dass die Ressource nur dann übermittelt wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur dann zu übermitteln, wenn der Cache veraltet ist.
If-Unmodified-Since: Macht die Anfrage bedingt und erwartet, dass die Ressource nur dann übermittelt wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies stellt die Kohärenz eines neuen Fragmentes eines bestimmten Bereiches mit den vorherigen sicher oder ermöglicht die Implementierung eines optimistischen Concurrency-Control-Systems beim Ändern bestehender Dokumente.
Vary: Bestimmt, wie Anfragen-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue von dem Ursprung-Server anzufordern.

Verbindungsmanagement

Connection: Steuert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion offen bleibt.
Keep-Alive: Steuert, wie lange eine persistente Verbindung offen bleiben soll.

Inhaltsaushandlung

Weitere Einzelheiten finden Sie im Artikel Inhaltsaushandlung.

Accept: Informiert den Server über die Typen von Daten, die zurückgesendet werden können.
Accept-Encoding: Der Kodierungsalgorithmus, üblicherweise ein Kompressionsalgorithmus, der auf der zurückgesendeten 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 Nutzers: Der Server sollte immer darauf achten, eine explizite Nutzerauswahl (wie etwa die Auswahl einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.
Accept-Patch: Ein request content negotiation-Antwort-Header, der angibt, welchen Medientyp der Server in einer PATCH-Anfrage verstehen kann.
Accept-Post: Ein request content negotiation-Antwort-Header, der angibt, welchen Medientyp der Server in einer POST-Anfrage verstehen kann.

Steuerungen

Expect: Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu verarbeiten.
Max-Forwards: Bei Verwendung von TRACE, gibt die maximale Anzahl von Hops an, die die Anfrage durchlaufen kann, bevor sie an den Absender reflektiert 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 Benutzer-Agenten.

CORS

Für mehr Informationen, siehe die CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Anmeldezeugnis-Flag wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header bei der eigentlichen 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 freigegeben 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 beim Erteilen einer Preflight-Anfrage verwendet, um den Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird beim Erteilen einer Preflight-Anfrage verwendet, um den 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 die Werte von Attributen sehen dürfen, die über Funktionen der Resource Timing API abgerufen werden, die ansonsten aufgrund von Cross-Origin-Beschränkungen als Null gemeldet werden würden.

Downloads

Content-Disposition: Gibt an, ob die übermittelte 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 präsentieren sollte.

Integritäts-Digests

Content-Digest Experimentell: Bietet einen Digest des Oktettstroms, der in einer HTTP-Nachricht gerahmt ist (der Nachrichteninhalt), abhängig von Content-Encoding und Content-Range.
Repr-Digest Experimentell: Bietet einen Digest der ausgewählten Repräsentation der Zielressource vor der Übertragung. Anders als der Content-Digest berücksichtigt der Digest nicht Content-Encoding oder Content-Range.
Want-Content-Digest Experimentell: Teilt den Wunsch nach einem Content-Digest-Header mit. Es ist das Content- Gegenstück zu Want-Repr-Digest.
Want-Repr-Digest Experimentell: Teilt den Wunsch nach einem Repr-Digest-Header mit. Es ist das Repr- Gegenstück zu Want-Content-Digest.

Informationen zum Nachrichteninhalt

Content-Length: Die Größe der Ressource in Dezimalzahl Bytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Wird verwendet, um den Komprimierungsalgorithmus zu spezifizieren.
Content-Language: Beschreibt die menschliche(n) Sprache(n), die für das Publikum vorgesehen sind, damit ein Nutzer je nach seinen eigenen bevorzugten Sprachen unterscheiden kann.
Content-Location: Gibt einen alternativen Ort für die zurückgegebenen Daten an.

Proxys

Forwarded: Enthält Informationen von der klientenseitigen Seite der Proxy-Server, die verändert oder verloren gehen, wenn ein Proxy auf dem Anforderungspfad beteiligt ist.
Via: Wird von Proxys hinzugefügt, sowohl vorwärts- als auch rückwärts-Proxys, und kann sowohl in den Anfrage- als auch in den Antwort-Headern erscheinen.

Teilbereichsanforderungen

HTTP Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Media-Player, die zufälligen Zugriff unterstützen, Datentools, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Download-Manager, die 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 aus inkompatiblen Versionen der Ressource zu verhindern.
Content-Range: Gibt an, wo in einer vollständigen Nachrichten ein Teilnachricht zu platzieren ist.

Umleitungen

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

Anforderungskontext

From: Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden Benutzer-Agenten kontrolliert.
Host: Gibt den Domainnamen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server lauscht.
Referer: Die Adresse der vorherigen Webseite, von der aus ein Link auf die aktuell angeforderte Seite gefolgt wurde.
Referrer-Policy: Bestimmt, welche Referrer-Informationen, die im Referer-Header gesendet werden, bei Anfragen enthalten sein sollen.
User-Agent: Enthält eine charakteristische Zeichenfolge, die den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfragenden Benutzer-Agenten zu identifizieren.

Antwortkontext

Allow: Listet die unterstützten HTTP-Anfrage-Methoden einer Ressource 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 erklären.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domänen ein Fenster öffnen/kontrollieren.
Cross-Origin-Resource-Policy (CORP): Verhindert, dass andere Domänen die Antwort auf die Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch CORP Explainer Artikel.
Content-Security-Policy (CSP): Kontrolliert Ressourcen, die der Benutzer-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Erlaubt Webentwicklern, mit Richtlinien zu experimentieren, indem ihre Effekte überwacht, aber nicht erzwungen werden. Diese Verletzungsberichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.
Expect-CT Veraltet: Ermöglicht es Websites, die Berichterstattung und Durchsetzung von Zertifikatstransparenz zu aktivieren, um die Verwendung von missbräuchlich ausgestellten Zertifikaten für diese Site zu erkennen.
Permissions-Policy: Bietet einen Mechanismus zum Erlauben und Verweigern der Verwendung von Browserfunktionen im eigenen Frame einer Website und in <iframe>s, die sie einbettet.
Reporting-Endpoints Experimentell: Antwort-Header, der Website-Betreibern die Angabe von einem oder mehreren Endpunkten ermöglicht, die zum Empfang von Fehlern wie CSP-Verletzungsberichten, Cross-Origin-Opener-Policy-Berichten oder anderen allgemeinen Verletzungen verwendet werden.
Strict-Transport-Security (HSTS): Erzwingt die Kommunikation über HTTPS anstelle von HTTP.
Upgrade-Insecure-Requests: Sendet ein Signal an den Server, das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt und dass er die upgrade-insecure-requests-Direktive erfolgreich handhaben kann.
X-Content-Type-Options: Deaktiviert MIME-Sniffing und zwingt den Browser, den im Content-Type angegebenen Typ zu verwenden.
X-Frame-Options (XFO): Gibt an, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern sollte.
X-Permitted-Cross-Domain-Policies: Eine Cross-Domain-Richtliniendatei kann Clients, wie Adobe Acrobat oder Apache Flex (unter anderem), die Erlaubnis gewähren, Daten über Domänen hinweg zu verarbeiten, die ansonsten aufgrund der Same-Origin-Policy eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients ungewollte Anfragen weiterhin blockieren.
X-Powered-By: Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, bietet jedoch keinen Nutzen für die Anwendung oder deren Besucher. Entfernen Sie diesen Header, um potenzielle Schwachstellen nicht offenzulegen.
X-XSS-Protection: Aktiviert das Cross-Site-Skriptfilterung.

Fetch Metadata Anfrage-Header

Fetch Metadata Anfrage-Header stellen Informationen über den Kontext bereit, aus dem die Anfrage stammt. Ein Server kann sie verwenden, um Entscheidungen zu treffen, ob eine Anfrage erlaubt werden soll, basierend darauf, woher die Anfrage kam und wie die Ressource verwendet wird.

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprungsort eines Anforderungsinitiators und dem Zielort an. Es ist ein strukturiertes 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 für einen Server an. Es ist ein strukturiertes 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 ist ein strukturiertes Header, dessen Wert ein boolesches ist, sodass die möglichen Werte ?0 für falsch und ?1 für wahr sind.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es ist ein strukturiertes 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 Anfragen-Header sind nicht streng genommen "Fetch-Metadata-Anfrage-Header", aber sie liefern ähnlich Informationen über den Kontext, wie eine Ressource verwendet werden wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten zu ändern oder die zurückgegebenen Informationen:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes ist als die unmittelbare Nutzung durch den Benutzer-Agenten. Der Header hat derzeit einen möglichen Wert, prefetch, der anzeigt, dass die Ressource präventiv für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anfrage-Header, der in einer präemptiven Anfrage gesendet wird, um eine Ressource während des Startvorgangs des Service Workers mit fetch() abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server zu informieren, dass eine andere Ressource zurückgegeben werden sollte als bei einer normalen fetch()-Operation.

Server-gesendete Ereignisse

Reporting-Endpoints: Antwort-Header, der verwendet wird, um Server-Endpunkte zu spezifizieren, an denen der Browser Warn- und Fehlerberichte beim Verwenden der Reporting API senden soll.
Report-To Veraltet Nicht standardisiert: Antwort-Header, der verwendet wird, um Server-Endpunkte zu spezifizieren, an denen der Browser Warn- und Fehlerberichte beim Verwenden der Reporting API senden soll.

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 Benutzerclient akzeptieren möchte.
Trailer: Ermöglicht dem Sender, 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: Antwort-Header, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung aufzurüsten.
Sec-WebSocket-Extensions: In Anfragen zeigt dieser Header die vom Client bevorzugten WebSocket-Erweiterungen an. In Antworten gibt er die vom Server aus den Vorlieben des Clients ausgewählte Erweiterung an.
Sec-WebSocket-Key: Anfrage-Header, der einen Schlüssel enthält, der verifiziert, dass der Client ausdrücklich beabsichtigt, eine WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen zeigt dieser Header die vom Client bevorzugten Subprotokolle an. In Antworten gibt er das aus den Vorlieben des Clients ausgewählte Subprotokoll an.
Sec-WebSocket-Version: In Anfragen zeigt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn die angeforderte Protokollversion nicht vom Server unterstützt wird, und listet die vom Server unterstützten Versionen auf.

Andere

Alt-Svc: Wird verwendet, um alternative Möglichkeiten zum Erreichen dieses Dienstes aufzulisten.
Alt-Used: Wird verwendet, um den gerade verwendeten alternativen Dienst zu identifizieren.
Date: Enthält das Datum und die Uhrzeit, zu der die Nachricht ursprünglich erstellt wurde.
Link: Dieses Entity-Header-Feld bietet ein Mittel 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 Benutzer-Agent warten soll, bevor eine Folgeanfrage gestellt wird.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anforderungs-Antwort-Zyklus.
Service-Worker: Wird in Abrufen für das Skriptressourcen eines Service Workers hinzugefügt. Dieser Header hilft Administratoren, Anfragen von Service Worker-Skriptdateien zu protokollieren, um Überwachungszwecke zu erfüllen.
Service-Worker-Allowed: Wird verwendet, um die Pfadbeschränkung durch die Aufnahme dieses Headers in die Antwort des Service Worker-Skripts zu beheben.
SourceMap: Link zu einer Quellkarte, damit Debugger durch den ursprünglichen Quellcode anstelle von generiertem oder transformiertem Code schrittweise laufen können.
Upgrade: Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits bestehende Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Beispielsweise kann es von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 zu HTTP 2.0 oder eine HTTP- oder HTTPS-Verbindung in ein WebSocket zu aktualisieren.
Priority: Bietet einen Hinweis über die Priorität einer bestimmten Ressourcenanforderung auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Priorität des Clients anzugeben, oder in einer Antwort, wenn der Server beschließt, die Anforderung neu zu priorisieren.

Experimentelle Header

Attribution Reporting Header

Die Attribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen – zum Beispiel, wenn ein Benutzer auf eine Anzeige klickt, die auf einer Website eingebettet ist, und dann auf der Website des Anbieters das Produkt kauft – und dann Berichte über diese Konversionen abzurufen. Sie tut dies, ohne auf Drittanbieter-Cookies zurückzugreifen, sondern verwendet stattdessen verschiedene Header, um Quellen und Auslöser zu registrieren, die eine Konversion anzeigen.

Attribution-Reporting-Eligible: Wird verwendet, um anzuzeigen, dass die Antwort, die mit der aktuellen Anfrage übereinstimmt, berechtigt ist, an der Attribution-Reporting teilzunehmen, indem entweder eine Attributionsquelle oder ein Auslöser registriert wird.
Attribution-Reporting-Register-Source: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible Header enthielt, verwendet, um eine 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 Attributionsauslöser zu registrieren.

Client-Hinweise

HTTP Client-Hinweise sind eine Reihe von Anfrage-Headern, die nützliche Informationen über den Client wie Gerätetyp und Netzwerkbedingungen liefern und es Servern ermöglichen, das Servierte für diese Bedingungen zu optimieren.

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

Accept-CH: Server können die Unterstützung für Client-Hinweise mit dem Accept-CH Header-Feld oder einem äquivalenten HTML <meta>-Element mit dem Attribut http-equiv anzeigen.
Critical-CH Experimentell: Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client-Hinweise auch kritische Client-Hinweise sind.

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

Benutzer-Agent-Client-Hinweise

Die UA Client-Hinweise sind Anfrage-Header, die Informationen über den Benutzer-Agenten, die Plattform/Architektur, auf der er läuft, und Benutzereinstellungen, die auf dem Benutzer-Agenten oder der Plattform festgelegt sind, bereitstellen:

Sec-CH-UA Experimentell: Marken- und Versionsinformationen des Benutzer-Agenten.
Sec-CH-UA-Arch Experimentell: Die zugrunde liegende Plattformarchitektur des Benutzer-Agenten.
Sec-CH-UA-Bitness Experimentell: Bitness der zugrunde liegenden CPU-Architektur des Benutzer-Agenten (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factor Experimentell: Formfaktoren des Benutzer-Agenten, die beschreiben, wie der Benutzer mit dem Benutzer-Agenten interagiert.
Sec-CH-UA-Full-Version Veraltet: Vollständige Versionszeichenfolge des Benutzer-Agenten.
Sec-CH-UA-Full-Version-List Experimentell: Vollständige Version für jede Marke in der Markenliste des Benutzer-Agenten.
Sec-CH-UA-Mobile Experimentell: Der Benutzer-Agent läuft auf einem mobilen Gerät oder bevorzugt im Allgemeinen eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model Experimentell: Gerätmodell des Benutzer-Agenten.
Sec-CH-UA-Platform Experimentell: Betriebssystem-/Plattform des Benutzer-Agenten.
Sec-CH-UA-Platform-Version Experimentell: Version des Betriebssystem des Benutzer-Agenten.
Sec-CH-UA-WoW64 Experimentell: Ob der Benutzer-Agent läuft im 32-Bit-Modus auf 64-Bit-Windows.
Sec-CH-Prefers-Color-Scheme Experimentell: Vorliebe des Benutzers für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion Experimentell: Vorliebe des Benutzers, weniger Animationen und Inhaltslayoutsverschiebungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anfrage-Header zeigt die Vorliebe des Benutzer-Agenten für reduzierte Transparenz an.

Hinweis: Benutzer-Agent-Client-Hinweise sind nicht innerhalb von fenced frames verfügbar, weil sie auf Berechtigungsrichtliniendelegation basieren, die genutzt werden könnte, um Daten zu leaken.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert: Antwort-Header, der verwendet wird, um das Bild-Gerät-zu-Pixel-Verhältnis (DPR) in Anfragen zu bestätigen, bei denen der Bildschirm DPR Client-Hinweis verwendet wurde, um eine Bildressource auszuwählen.
Device-Memory: Ungefähre Menge der verfügbaren Client-RAM-Speicher. Dies ist Teil der Device Memory API.
DPR Veraltet Nicht standardisiert: Anfrage-Header, der das Pixelverhältnis des Clientgeräts angibt (die Anzahl der physischen Gerätepixel für jedes CSS-Pixel).
Viewport-Width Veraltet Nicht standardisiert: Anfrage-Header gibt die Layout-Ansichtbereichsbreite des Clients in CSS-Pixel an.
Width Veraltet Nicht standardisiert: Anfrage-Header zeigt die gewünschte Ressourcenbreite in physikalischen Pixeln an (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise ermöglichen es einem Server zu entscheiden, auf Grundlage der Benutzerwahl und der Netzwerkauslastung und Latenz, welche Informationen gesendet werden sollen.

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"), der am besten zur Verzögerung und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.
RTT Experimentell: Anwendungsbenutzerlagen-Rundlaufzeit (RTT) in Millisekunden, die die Serverbearbeitungszeit einschließt. Dies ist Teil der Network Information API.
Save-Data Experimentell: Ein on, das die Präferenz des Benutzer-Agenten für eine reduzierte Datennutzung angibt.

Privatsphäre

DNT Veraltet Nicht standardisiert: Anfrage-Header, der die Präferenz des Benutzers zum Tracking angibt (Do Not Track). Veraltet zugunsten der Global Privacy Control (GPC), die den Servern über den Sec-GPC-Header mitgeteilt wird und den Clients über navigator.globalPrivacyControl zugänglich ist.
Tk Veraltet Nicht standardisiert: Antwort-Header, der den Tracking-Status angibt, der für die entsprechende Anfrage galt. Verwendung in Verbindung mit DNT.
Sec-GPC Nicht standardisiert Experimentell: Gibt an, ob der Benutzer einer Website oder einem Dienst zustimmt, seine persönlichen Informationen mit Dritten zu verkaufen oder zu teilen.

Sicherheit

Origin-Isolation Experimentell: Bietet einen Mechanismus, um Webanwendungen zu erlauben, ihre Ursprünge zu isolieren.

Server-gesendete Ereignisse

NEL Experimentell: Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Netzwerkausfall-Meldepolitik zu erklären.

Themen-API

Die Topics API stellt einen Mechanismus bereit, mit dem Entwickler Anwendungsfälle wie interessenbasierte Werbung (IBA) implementieren können. Weitere Informationen finden Sie in der Topics API-Dokumentation.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwort-Header, der verwendet wird, um Themen von Interesse, die aus der URL einer aufrufenden Seite abgeleitet wurden, als in der Antwort auf eine Anfrage beobachtet zu markieren, die von einer Funktion, die die Topics API aktiviert, generiert wurde.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Anfrage-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Werbetechnologieplattform verwendet werden, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.

Sonstiges

Accept-Signature Experimentell: Ein Client kann den Accept-Signature-Header-Feld senden, um die Absicht anzugeben, vorhandene Signaturen zu nutzen und anzugeben, welche Arten von Signaturen er unterstützt.
Early-Data Experimentell: Gibt an, dass die Anfrage in TLS frühe Daten übermittelt wurde.
Origin-Agent-Cluster Experimentell: Antwort-Header, der verwendet wird, um anzuzeigen, dass das zugehörige Dokument in ein Ursprung-gekapseltes Agent-Cluster platziert werden soll. Diese Isolierung ermöglicht es Benutzer-Agenten, implementierungsspezifische Ressourcen wie Prozesse oder Threads für Agent-Cluster effizienter zuzuweisen.
Set-Login Experimentell: Antwort-Header, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Login-Status zu setzen, also 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 überträgt eine Liste von Signaturen für einen Austausch, jede mit Informationen darüber, wie die Autorität bestimmt und die Signatur erneuert werden kann.
Signed-Headers Experimentell: Das Signed-Headers-Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur aufgenommen werden sollen.
Speculation-Rules Experimentell: Bietet eine Liste von URLs, die auf Textressourcen verweisen, die Spekulationsregel JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zur Spekulationsregelmenge des Dokuments hinzugefügt.
Supports-Loading-Mode Experimentell: Wird von einem Navigationstarget festgelegt, um die Verwendung verschiedener risikoreicher Lademodi zu ermöglichen. Beispielsweise erfordert das Prerendering von Sitzungen mit berechtigter Nutzung dasselbe Präfix-Präfix credentialed-prerender.

Nicht-standardmäßige Header

X-Forwarded-For Nicht standardisiert: Identifiziert die ursprünglichen IP-Adressen eines Clients, der eine Verbindung zu einem Webserver über einen HTTP-Proxy oder einen Lastverteiler herstellt.
X-Forwarded-Host Nicht standardisiert: Identifiziert den ursprünglichen Host, der angefordert wurde und den ein Client verwendet hat, um sich mit Ihrem Proxy oder Load-Balancer zu verbinden.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um eine Verbindung mit Ihrem Proxy oder Load-Balancer herzustellen.
X-DNS-Prefetch-Control Nicht standardisiert: Steuert das DNS-Prefetching, eine Funktion, mit der Browser proaktiv die Namensauflösung von Domains sowohl für Links durchführen, die ein Benutzer möglicherweise auswählt, als auch für URLs von Elementen, die von dem Dokument referenziert werden, einschließlich Bilder, CSS, JavaScript usw.
X-Robots-Tag Nicht standardisiert: Der X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb der öffentlichen Suchmaschinenergebnisse indiziert werden soll. Der Header ist effektiv äquivalent zu <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet: Implementierungsspezifischer Header, der an jedem Punkt in der Anforderung-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.

Beitrag leisten

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