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 auf Groß- und Kleinschreibung beachtender Name, gefolgt von einem Doppelpunkt, dann optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel: Allow: POST
).
In HTTP/2 und darüber hinaus werden Header in Kleinbuchstaben angezeigt, wenn sie in Entwicklerwerkzeugen 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 es verursachte, als nicht standardmäßige Felder in RFC 6648 standardisiert wurden, aufgegeben; 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 nach ihren Kontexten gruppiert werden:
- Request-Header
-
Enthalten weitere 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 über den Server, der sie bereitstellt.
- Representation-Header
-
Enthalten Informationen über den Körper der Ressource, wie ihren MIME-Typ oder die angewendete Kodierung/Kompression.
- Payload-Header
-
Enthalten darstellungsunabhängige Informationen über Nutzdaten, einschließlich Inhaltslänge und der für den Transport verwendeten Kodierung.
Header können auch danach gruppiert werden, wie Proxies mit ihnen umgehen:
- End-to-End-Header
-
Diese Header müssen an den Endempfänger der Nachricht übermittelt werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenproxies müssen diese Header unverändert weiterleiten, und Caches müssen sie speichern.
- Hop-by-Hop-Header
-
Diese Header sind nur für eine einzelne Transportschichtverbindung von Bedeutung und dürfen nicht von Proxies weitergeleitet oder zwischengespeichert werden. Hinweis: Nur Hop-by-Hop-Header können mit dem
Connection
-Header festgelegt werden.
Authentifizierung
WWW-Authenticate
-
Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource zuzugreifen.
-
Enthält die Anmeldedaten, um einen Benutzer-Agenten gegenüber einem Server zu authentifizieren.
Proxy-Authenticate
-
Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource hinter einem Proxy-Server zuzugreifen.
-
Enthält die Anmeldedaten, um einen Benutzer-Agenten gegenüber einem Proxy-Server zu authentifizieren.
Caching
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 anfragenden Website verbunden sind.
Expires
-
Das Datum/die Uhrzeit, nach der die Antwort als veraltet angesehen wird.
No-Vary-Search
Experimentell-
Gibt eine Reihe von Regeln an, die definieren, wie sich die Abfrageparameter einer URL auf die Cache-Abstimmung auswirken werden. Diese Regeln bestimmen, ob die gleiche URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.
Konditionale 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 einigen Umgebungen einfacher zu berechnen. Bedingte Anfragen mitIf-Modified-Since
undIf-Unmodified-Since
verwenden diesen Wert, um das Verhalten der Anfrage zu ändern. ETag
-
Eine eindeutige Zeichenkette, die die Version der Ressource identifiziert. Bedingte Anfragen mit
If-Match
undIf-None-Match
verwenden diesen Wert, um das Verhalten der Anfrage zu ändern. If-Match
-
Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.
If-None-Match
-
Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource nicht mit einem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen) oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine vorhanden ist.
If-Modified-Since
-
Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur dann 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 geändert wurde. Dies stellt die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorhergehenden sicher oder implementiert ein optimistisches Synchronisationskontrollsystem, wenn bestehende Dokumente geändert werden.
Vary
-
Bestimmt, wie Anforderungs-Header abgeglichen werden sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver zu erfragen.
Verbindungsverwaltung
Connection
-
Kontrolliert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion geöffnet bleibt.
Keep-Alive
-
Kontrolliert, wie lange eine persistente Verbindung geöffnet bleiben soll.
Inhaltsaushandlung
Für weitere Details lesen Sie den Artikel zur Inhaltsaushandlung.
Accept
-
Informiert den Server über die Typen von Daten, die zurückgesendet werden können.
Accept-Encoding
-
Der Kodierungsalgorithmus, normalerweise ein 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 darauf achten, eine explizite Benutzerwahl nicht zu überschreiben (wie das Auswählen einer Sprache aus einem Dropdown-Menü).
Accept-Patch
-
Ein Request Content Negotiation-Antwort-Header, der angibt, welcher Medientyp der Server in einer
PATCH
-Anfrage verstehen kann. Accept-Post
-
Ein Request Content Negotiation-Antwort-Header, der angibt, welcher Medientyp der Server in einer
POST
-Anfrage verstehen kann.
Steuerung
Expect
-
Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage richtig zu bearbeiten.
Max-Forwards
-
Gibt bei der Verwendung von
TRACE
die maximale Anzahl von Hops an, die die Anfrage durchlaufen darf, bevor sie zum Absender zurückgespiegelt wird.
Cookies
-
Enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem
Set-Cookie
-Header gesendet wurden. -
Sendet Cookies vom Server an den Benutzer-Agenten.
CORS
Für weitere Informationen lesen Sie die CORS-Dokumentation.
Access-Control-Allow-Credentials
-
Gibt an, ob die Antwort auf die Anfrage offen gelegt werden kann, wenn das Anmeldeinformationen-Flag wahr ist.
Access-Control-Allow-Headers
-
Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzuzeigen, welche HTTP-Header bei der eigentlichen Anforderung verwendet werden dürfen.
Access-Control-Allow-Methods
-
Gibt die erlaubten Methoden beim Zugriff auf die Ressource als Antwort auf eine Preflight-Anfrage an.
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 im Cache gehalten werden können.
Access-Control-Request-Headers
-
Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die eigentliche Anforderung gestellt wird.
Access-Control-Request-Method
-
Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Methode bei der eigentlichen Anfrage verwendet wird.
Origin
-
Gibt an, woher ein Abruf stammt.
Timing-Allow-Origin
-
Gibt die Ursprünge an, die berechtigt sind, Werte von Attributen zu sehen, die über Funktionen der Resource Timing API abgerufen wurden, die sonst 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 sollte und der Browser einen "speichern unter" Dialog präsentieren soll.
Integritätsprüfsummen
Content-Digest
Experimentell-
Bietet eine Prüfsumme des Stroms von Oktetten, die in einer HTTP-Nachricht eingerahmt sind (den Nachrichteninhalt), abhängig von
Content-Encoding
undContent-Range
. Repr-Digest
Experimentell-
Bietet eine Prüfsumme der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zu
Content-Digest
berücksichtigt die Prüfsumme wederContent-Encoding
nochContent-Range
. Want-Content-Digest
Experimentell-
Gibt den Wunsch nach einem
Content-Digest
-Header an. Es ist dasContent-
Analoge zuWant-Repr-Digest
. Want-Repr-Digest
Experimentell-
Gibt den Wunsch nach einem
Repr-Digest
-Header an. Es ist dasRepr-
Analoge zuWant-Content-Digest
.
Integritätspolitik
Integrity-Policy
-
Stellt sicher, dass alle Ressourcen, die vom Benutzer-Agenten geladen werden (einer bestimmten Art), Subresource Integrity-Garantien erfüllen.
Integrity-Policy-Report-Only
-
Berichtet über Ressourcen, die der Benutzer-Agent lädt, die Subresource Integrity-Garantien verletzen würden, wenn die Integritätspolitik durchgesetzt würde (mit dem
Integrity-Policy
-Header).
Nachrichtenkörperinformationen
Content-Length
-
Die Größe der Ressource in dezimaler Anzahl von Bytes.
Content-Type
-
Gibt den Medientyp der Ressource an.
Content-Encoding
-
Verwendet, um den Komprimierungsalgorithmus anzugeben.
Content-Language
-
Beschreibt die menschliche(n) Sprache(n), die für das Publikum bestimmt sind, sodass es einem Benutzer erlaubt, nach den eigenen bevorzugten Sprachen zu differenzieren.
Content-Location
-
Gibt einen alternativen Speicherort für die zurückgegebenen Daten an.
Präferenzen
Präferenzen können von Clients in Anfragen gesendet werden, um optionale Verhaltensweisen für Anfragen und Antworten anzuzeigen. Die Serverantwort kann angeben, ob eine Präferenz angewendet wird, in Fällen, in denen es ansonsten für den Client zweideutig wäre. Browser verfügen über keine native Unterstützung, um Präferenzen über diese Header zu senden; sie werden in benutzerdefinierten, implementationsspezifischen Clients verwendet.
Prefer
-
Gibt Präferenzen für bestimmte Serververhalten während der Anfrageverarbeitung an. Beispielsweise kann es minimale Antwortinhalte (
return=minimal
) oder asynchrone Verarbeitung (respond-async
) anfordern. Der Server verarbeitet die Anfrage normal, wenn der Header nicht unterstützt wird. Preference-Applied
-
Informiert den Client darüber, welche Präferenzen, die im
Prefer
-Header angegeben wurden, vom Server angewendet wurden. Es ist ein reiner Antwort-Header, der Transparenz über die Präferenzbehandlung bietet.
Proxies
Forwarded
-
Enthält Informationen von der Client-seitigen Seite von Proxy-Servern, die geändert oder verloren gehen, wenn ein Proxy im Anforderungspfad beteiligt ist.
Via
-
Wird von Proxies hinzugefügt, sowohl von Forward- als auch von Reverse-Proxies, und kann sowohl in den Anfrage-Headern als auch in den 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 Mediaplayer, die zufälligen Zugriff unterstützen, Datentools, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Downloadmanager, die dem Benutzer erlauben, einen Download zu pausieren und fortzusetzen.
Accept-Ranges
-
Zeigt 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 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 Nachricht ein Teil der Nachricht gehört.
Umleitungen
Location
-
Gibt die URL an, zu der eine Seite umgeleitet werden soll.
Refresh
-
Weist den Browser an, die Seite neu zu laden oder zu einer anderen umzuleiten. Nimmt denselben Wert wie das
meta
-Element mithttp-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 Virtual Hosting) und (optional) die TCP-Portnummer, auf der der Server lauscht.
Referer
-
Die Adresse der vorherigen Webseite, von der aus ein Link zur derzeit angeforderten Seite gefolgt wurde.
Referrer-Policy
-
Regelt, welche Referrerinformationen 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-Agenten zu identifizieren.
Antwortkontext
Sicherheit
Cross-Origin-Embedder-Policy
(COEP)-
Ermöglicht einem Server, eine Einbettungsrichtlinie für ein gegebenes Dokument zu deklarieren.
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 der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch CORP-Erklärungsartikel.
Content-Security-Policy
(CSP)-
Kontrolliert Ressourcen, die der Benutzer-Agent laden darf, für eine gegebene Seite.
Content-Security-Policy-Report-Only
-
Ermöglicht Webentwicklern, Richtlinien zu testen, indem ihre Auswirkungen überwacht, aber nicht durchgesetzt werden. Diese Verstöße-Berichte bestehen aus JSON-Dokumenten, die über eine HTTP-
POST
-Anfrage an die angegebene URI gesendet werden. Expect-CT
Veraltet-
Ermöglicht es Websites, bei der Berichterstattung und Durchsetzung von Zertifikatstransparenz opt-in zu wählen, um die Verwendung von fehlerhaften Zertifikaten für diese Website zu erkennen.
Permissions-Policy
-
Bietet einen Mechanismus, um die Verwendung von Browserfunktionen in einem eigenen Rahmen einer Website und in
<iframe>
s, die sie einbettet, zu erlauben oder zu verbieten. Reporting-Endpoints
Experimentell-
Antwort-Header, der es Website-Besitzern ermöglicht, einen oder mehrere Endpunkte anzugeben, die verwendet werden, um Fehler wie CSP-Verletzungsberichte,
Cross-Origin-Opener-Policy
-Berichte oder andere generische 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, dass der Client eine präferenzierte, verschlüsselte und authentifizierte Antwort wünscht und dass er erfolgreich die
upgrade-insecure-requests
-Direktive behandeln kann. X-Content-Type-Options
-
Deaktiviert 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 Crosse-Domain-Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domänen hinweg zu verarbeiten, die aufgrund der Same-Origin Policy ansonsten eingeschränkt wären. Der
X-Permitted-Cross-Domain-Policies
-Header überschreibt solche Richtliniendateien, sodass Clients weiterhin unerwünschte Anfragen blockieren. X-Powered-By
-
Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über sie, ohne dass dies für die Anwendung oder ihre Besucher von Nutzen ist. Entfernen Sie diesen Header, um potenzielle Schwachstellen zu verbergen.
X-XSS-Protection
-
Aktiviert das Filtern von Cross-Site-Scripting.
Fetch-Metadatenanforderungs-Header
Fetch-Metadatenanforderungs-Header bieten Informationen über den Kontext, aus dem die Anforderung stammt. Ein Server kann sie verwenden, um Entscheidungen darüber zu treffen, ob eine Anfrage erlaubt werden sollte, basierend darauf, woher die Anfrage kam und wie die Ressource verwendet wird.
Sec-Fetch-Site
-
Gibt das Verhältnis zwischen dem Ursprung eines Anforderungsinitiators und dem Zielursprung an. Es ist ein Structured Header, dessen Wert ein Token mit möglichen Werten
cross-site
,same-origin
,same-site
undnone
ist. Sec-Fetch-Mode
-
Gibt den Modus der Anforderung an einen Server an. Es ist ein Structured Header, dessen Wert ein Token mit möglichen Werten
cors
,navigate
,no-cors
,same-origin
undwebsocket
ist. Sec-Fetch-User
-
Gibt an, ob eine Navigationsanfrage durch Benutzeraktivierung ausgelöst wurde oder nicht. Es ist ein Structured Header, dessen Wert ein Boolescher Wert ist, sodass mögliche Werte
?0
für falsch und?1
für wahr sind. Sec-Fetch-Dest
-
Gibt das Ziel der Anfrage an. Es ist ein Structured 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
undxslt
ist.
Die folgenden Anforderungsheader sind nicht streng "Fetch-Metadatenanforderungs-Header", bieten aber ähnliche Informationen über den Kontext der Nutzung einer Ressource. Ein Server könnte sie verwenden, um sein Cache-Verhalten zu ändern oder die zurückgegebenen Informationen zu modifizieren:
Sec-Purpose
-
Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als der unmittelbare Nutzen durch den Benutzer-Agenten ist. Der Header hat derzeit einen möglichen Wert,
prefetch
, was anzeigt, dass die Ressource vorab für eine mögliche zukünftige Navigation abgerufen wird. -
Ein Anforderungs-Header, der in einer vorzeitigen Anforderung zum
fetch()
einer Ressource während des Service-Worker-Starts gesendet wird. Der Wert, der mitNavigationPreloadManager.setHeaderValue()
gesetzt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource zurückgegeben werden sollte als bei einem normalenfetch()
-Vorgang.
Server-sent Events
Reporting-Endpoints
-
Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, wohin der Browser Warn- und Fehlerberichte beim Verwenden der Reporting API senden soll.
Report-To
Veraltet Nicht standardisiert-
Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, wohin 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 Transferkodierungen an, die der Benutzer-Agent akzeptieren kann.
Trailer
-
Ermöglicht dem Absender, am Ende einer chunked-Nachricht zusätzliche Felder aufzunehmen.
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 heraufzustufen.
Sec-WebSocket-Extensions
-
In Anfragen gibt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. 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 bestätigt, dass der Client explizit die Eröffnung eines
WebSocket
beabsichtigt. Sec-WebSocket-Protocol
-
In Anfragen gibt dieser Header die vom Client unterstützten Subprotokolle in bevorzugter Reihenfolge an. In Antworten gibt er das vom Server aus den Präferenzen des Clients ausgewählte Subprotokoll 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 nicht vom Server unterstützt wird, und listet die Versionen auf, die der Server unterstützt.
Andere
Alt-Svc
-
Wird verwendet, um alternative Wege aufzulisten, um diesen Dienst zu erreichen.
Alt-Used
-
Wird verwendet, um den im Einsatz befindlichen alternativen Dienst zu identifizieren.
Date
-
Enthält das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde.
Link
-
Dieses Entität-Header-Feld bietet eine Möglichkeit zur Serialisierung eines oder mehrerer Links in HTTP-Headern. Es ist semantisch äquivalent zu dem HTML
<link>
-Element. Retry-After
-
Gibt an, wie lange der Benutzer-Agent warten soll, bevor er eine Folgeanfrage stellt.
Server-Timing
-
Übermittelt ein oder mehrere Metriken und Beschreibungen für den gegebenen Anforderungs-Antwort-Zyklus.
Service-Worker
-
Wird in Abrufen für das Skriptressourcen eines Service-Workers eingeschlossen. Dieser Header hilft Administratoren, Anfragen nach Service-Worker-Skripten zu protokollieren, um Überwachungszwecke zu erfüllen.
Service-Worker-Allowed
-
Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header in der Antwort des Service-Worker-Skriptes enthalten ist.
SourceMap
-
Verlinkt zu einer Source Map, damit Debugger durch den ursprünglichen Quellcode statt durch generierten oder transformierten Code treten können.
Upgrade
-
Dieser HTTP/1.1- (nur) Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) aufzurüsten. Beispielsweise 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 einen WebSocket zu aktualisieren.
Priority
-
Bietet einen Hinweis auf die Priorität einer bestimmten Ressourcenanforderung auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Clientpriorität anzuzeigen oder in einer Antwort, wenn der Server sich entscheidet, die Anfrage neu zu priorisieren.
Experimentelle Header
Zurechnungsberichte-Header
Das Attribution Reporting API ermöglicht Entwicklern das Messen von Conversions – z. B. wenn ein Benutzer auf eine eingebettete Anzeige auf einer Website klickt und dann das Produkt auf der Website des Verkäufers kauft – und anschließend auf Berichte zu diesen Conversions zuzugreifen. Dies geschieht ohne den Einsatz von Drittanbieter-Cookies, sondern verlässt sich auf verschiedene Header, um Quellen und Auslöser zu registrieren, die übereinstimmen, um eine Conversion anzuzeigen.
Attribution-Reporting-Eligible
-
Wird verwendet, um anzugeben, dass die Antwort auf die aktuelle Anfrage für die Aufnahme in Zurechnungsberichte durch die Registrierung entweder einer Zurechnungsquelle oder eines Auslösers geeignet ist.
Attribution-Reporting-Register-Source
-
Wird als Teil einer Antwort auf eine Anfrage enthalten, die einen
Attribution-Reporting-Eligible
-Header enthielt, und wird verwendet, um eine Zurechnungsquelle zu registrieren. Attribution-Reporting-Register-Trigger
-
Wird als Teil einer Antwort auf eine Anfrage enthalten, die einen
Attribution-Reporting-Eligible
-Header enthielt, und wird verwendet, um einen Zurechnungsauslöser zu registrieren.
Client-Hinweise
HTTP-Client-Hinweise sind eine Reihe von Anforderungsheadern, die nützliche Informationen über den Client wie Gerätetyp und Netzwerkbedingungen bereitstellen und es Servern ermöglichen, das, was unter diesen Bedingungen bedient wird, zu optimieren.
Server bitten den Client proaktiv um die Client-Hinweise-Header, an denen sie interessiert sind, über Accept-CH
. Der Client kann dann entscheiden, ob er die angeforderten Header in nachfolgenden Anfragen enthalten möchte.
Accept-CH
-
Server können die Unterstützung für Client-Hinweise über das Feld
Accept-CH
im Header oder ein entsprechendes HTML<meta>
-Element mit dem Attributhttp-equiv
bewerben. Critical-CH
Experimentell-
Server verwenden
Critical-CH
zusammen mitAccept-CH
, um anzugeben, dass akzeptierte Client-Hinweise auch als kritische Client-Hinweise gelten.
Die verschiedenen Arten von Client-Hinweisen sind unten aufgelistet.
Benutzer-Agent-Client-Hinweise
Die UA-Client-Hinweise sind Anforderungsheader, die Informationen über den Benutzer-Agenten, die Plattform/Architektur, auf der er läuft, und Benutzerpräferenzen, die auf dem Benutzer-Agenten oder der Plattform festgelegt sind, bereitstellen:
Sec-CH-UA
Experimentell-
Marken- und Versionsangaben zum Benutzer-Agenten.
Sec-CH-UA-Arch
Experimentell-
Architektur der zugrunde liegenden Plattform des Benutzer-Agenten.
Sec-CH-UA-Bitness
Experimentell-
Bitbreite der zentralen Verarbeitungseinheit (CPU) Architektur des Benutzer-Agenten (z.B. "64" Bit).
Sec-CH-UA-Form-Factors
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-
Volle Version für jede Marke in der Liste der Marken des Benutzer-Agenten.
Sec-CH-UA-Mobile
Experimentell-
Benutzer-Agent läuft auf einem mobilen Gerät oder bevorzugt allgemein eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model
Experimentell-
Modell des Geräts des Benutzer-Agenten.
Sec-CH-UA-Platform
Experimentell-
Betriebssystem/Plattform, auf dem der Benutzer-Agent basiert.
Sec-CH-UA-Platform-Version
Experimentell-
Versionsangabe des Betriebssystems/der Plattform, auf dem/der der Benutzer-Agent basiert.
Sec-CH-UA-WoW64
Experimentell-
Ob das Binärprogramm des Benutzer-Agenten im 32-Bit-Modus auf einem 64-Bit-Windows betrieben wird.
Sec-CH-Prefers-Color-Scheme
Experimentell-
Bevorzugung des Benutzers für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion
Experimentell-
Bevorzugung des Benutzers, weniger Animationen und Layoutverschiebungen von Inhalten zu sehen.
Sec-CH-Prefers-Reduced-Transparency
Experimentell-
Anforderungs-Header zeigt die Präferenz des Benutzer-Agenten für reduzierte Transparenz an.
Hinweis: Benutzer-Agent-Client-Hinweise sind nicht innerhalb von fenced frames verfügbar, da sie auf Berechtigungsrichtlinien-Delegation beruhen, die verwendet werden könnte, um Daten zu leaken.
Geräte-Client-Hinweise
Content-DPR
Veraltet Nicht standardisiert-
Antwort-Header, der verwendet wird, um das Bildgerät zum Pixelverhä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 an verfügbarem RAM-Speicher des Clients. Dies ist Teil der Device Memory API.
DPR
Veraltet Nicht standardisiert-
Anforderungs-Header, der das Geräte-Pixel-Verhältnis des Clients bereitstellt (die Anzahl physischer Geräte-Pixel für jedes CSS-Pixel).
Viewport-Width
Veraltet Nicht standardisiert-
Anforderungs-Header, der die Layout-Breite des Clientviewport im CSS-Pixel bereitstellt.
Width
Veraltet Nicht standardisiert-
Anforderungs-Header, der die gewünschte Ressourcenbreite in physischen Pixeln (die intrinsische Größe eines Bildes) angibt.
Netzwerk-Client-Hinweise
Netzwerk-Client-Hinweise ermöglichen einem Server auszuwählen, welche Informationen basierend auf der Benutzerwahl und der 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"), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.
RTT
Experimentell-
Round-Trip-Zeit (RTT) auf Anwendungsebene in Millisekunden, die die Serververarbeitungszeit einschließt. Dies ist Teil der Network Information API.
Save-Data
Experimentell-
Ein String
on
, der die Präferenz des Benutzer-Agenten für eine reduzierte Datennutzung anzeigt.
Komprimierungs-Wörterbuchtransport
Komprimierungs-Wörterbuchtransport ist eine Möglichkeit, ein gemeinsames Komprimierungswörterbuch zu verwenden, um die Transportgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch bei Brotli-Komprimierung oder Zstandard-Komprimierung zu verwenden.
Available-Dictionary
Experimentell-
Ein Browser kann diesen Anforderungs-Header verwenden, um das beste Wörterbuch, das er für die Komprimierung verwenden kann, anzugeben.
Dictionary-ID
Experimentell-
Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource hat und der Server eine
id
für das Wörterbuch imUse-As-Dictionary
-Header bereitgestellt hat. Anfragen für Ressourcen, die das Wörterbuch verwenden können, haben einenAvailable-Dictionary
-Header und die vom Server bereitgestellte Wörterbuch-id
imDictionary-ID
-Header. Use-As-Dictionary
Experimentell-
Listet die Übereinstimmungskriterien auf, die das Wörterbuch für zukünftige Anfragen verwenden kann.
Datenschutz
DNT
Veraltet Nicht standardisiert-
Anforderungs-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Veraltet zugunsten des Global Privacy Control (GPC), das den Servern über den
Sec-GPC
-Header mitgeteilt wird und übernavigator.globalPrivacyControl
für Clients zugänglich ist. Tk
Veraltet Nicht standardisiert-
Antwort-Header, der den Tracking-Status angibt, der für die entsprechende Anfrage galt. Wird in Verbindung mit DNT verwendet.
Sec-GPC
Nicht standardisiert Experimentell-
Gibt an, ob der Benutzer einer Website oder einem Dienst zustimmt, seine persönlichen Informationen an Dritte zu verkaufen oder weiterzugeben.
Sicherheit
Origin-Agent-Cluster
Experimentell-
Antwort-Header, der verwendet wird, um anzugeben, dass das zugehörige
Dokument
in einem ursprungsbezogenen Agenten-Cluster platziert werden soll. Diese Isolation ermöglicht es Benutzer-Agenten, Implementierungsspezifische Ressourcen für Agenten-Cluster wie Prozesse oder Threads effizienter zuzuweisen.
Server-sent Events
NEL
Experimentell-
Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Berichterstattungspolitik für Netzwerkfehler zu deklarieren.
Topics API
Die Topics API bietet eine Möglichkeit, Entwicklern die Implementierung von Anwendungsfällen wie interessenbasierte Werbung (IBA) zu ermöglichen. Siehe die Topics API Dokumentation für weitere Informationen.
Observe-Browsing-Topics
Experimentell Nicht standardisiert-
Antwort-Header, der verwendet wird, um Themen von Interesse, die aus der URL der aufrufenden Website ermittelt wurden, als beobachtet in der Antwort auf eine Anfrage zu markieren, die durch eine Funktion, die die Topics API ermöglicht generiert wurde.
Sec-Browsing-Topics
Experimentell Nicht standardisiert-
Anforderungs-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die 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
Header-Feld senden, um die Absicht anzugeben, die Vorteile verfügbarer Signaturen zu nutzen und die unterstützten Signaturarten anzugeben. Early-Data
Experimentell-
Gibt an, dass die Anfrage in TLS frühe Daten vermittelt wurde.
Set-Login
Experimentell-
Antwort-Header, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um dessen Anmeldestatus festzulegen, was bedeutet, ob auf dem aktuellen Browser Benutzer im IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM API verwendet.
Signature
Experimentell-
Der
Signature
Header-Feld übermittelt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität und Erneuerung dieser Signatur zu bestimmen ist. Signed-Headers
Experimentell-
Das
Signed-Headers
Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in einer Signatur enthalten sind. Speculation-Rules
Experimentell-
Bietet eine Liste von URLs, die auf Textressourcen verweisen, die Speculation-Rule JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Speculation-Rule-Set des Dokuments hinzugefügt.
-
Enthält einen oder mehrere Tag-Werte aus den Spekulationsregeln, die die Spekulation verursacht haben, sodass ein Server identifizieren kann, welche Regel(n) eine Spekulation verursacht haben und möglicherweise blockiert werden können.
Supports-Loading-Mode
Experimentell-
Wird von einem Navigationstarget gesetzt, um die Nutzung verschiedener, risikoreicher Lademodi zu unterstützen. Beispielsweise erfordert die Prerendering-Nutzung über Domänen hinweg, dass
Supports-Loading-Mode
den Wertcredentialed-prerender
hat.
Nicht standardmäßige Header
X-Forwarded-For
Nicht standardisiert-
Identifiziert die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder einen Lastausgleichsserver eine Verbindung zu einem Webserver herstellt.
X-Forwarded-Host
Nicht standardisiert-
Identifiziert den ursprünglichen Host, der von einem Client verwendet wurde, um eine Verbindung zu Ihrem Proxy- oder Lastausgleichsserver herzustellen.
X-Forwarded-Proto
Nicht standardisiert-
Identifiziert das Protokoll (HTTP oder HTTPS), das von einem Client verwendet wurde, um eine Verbindung zu Ihrem Proxy- oder Lastausgleichsserver herzustellen.
X-DNS-Prefetch-Control
Nicht standardisiert-
Steuert das DNS-Vorabrufen, ein Feature, bei dem Browser proaktiv die Domain-Name-Auflösung sowohl für Links durchführen, denen der Benutzer folgen könnte, als auch für URLs, die vom Dokument referenziert werden, einschließlich Images, CSS, JavaScript usw.
X-Robots-Tag
Nicht standardisiert-
Der
X-Robots-Tag
HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb öffentlicher Suchmaschinenergebnisse indiziert werden soll. Der Header ist gleichwertig zu<meta name="robots">
-Elementen.
Veraltete Header
Pragma
Veraltet-
Implementierungsspezifischer Header, der irgendwo in der Anforderungs-Antwort-Kette verschiedene Auswirkungen haben kann. Wird zur Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, wo der
Cache-Control
-Header noch nicht vorhanden ist. Warning
Veraltet-
Allgemeine Warninformationen über mögliche Probleme.