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 Groß-/Kleinschreibungssensitiver Name gefolgt von einem Doppelpunkt, dann einem optionalen Leerzeichen, das 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 für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt versehen (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.
Eigene, proprietäre Header wurden in der Vergangenheit mit einem X- Präfix verwendet, aber diese Konvention wurde 2012 aufgrund der Unannehmlichkeiten, die sie verursachte, als nicht standardisierte Felder zu Standards in RFC 6648 wurden, abgelehnt; andere sind im IANA HTTP Field Name Registry aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header, einschließlich Informationen über ihren Status.
Header können nach ihrem Kontext gruppiert werden:
- Anforderungsheader
-
Enthalten zusätzliche Informationen über die abzurufende Ressource oder über den Client, der die Ressource angefordert hat.
- Antwortheader
-
Enthalten zusätzliche Informationen über die Antwort, wie ihren Standort oder über den Server, der sie bereitstellt.
- Repräsentationsheader
-
Enthalten Informationen über den Körper der Ressource, wie ihren MIME-Typ oder die angewendete Kodierung/Kompression.
- Nutzlast-Header
-
Enthalten repräsentationsunabhängige Informationen über Nutzdaten, einschließlich der Inhaltslänge und der für den Transport verwendeten Kodierung.
Header können auch nach der Art und Weise gruppiert werden, wie Proxys sie verarbeiten:
- End-to-end-Header
-
Diese Header müssen an den letzten Empfänger der Nachricht übermittelt werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenliegende Proxys 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 transportstufenabhängige Verbindung von Bedeutung und dürfen nicht von Proxys weitergeleitet oder im Cache gespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mithilfe des
ConnectionHeaders festgelegt werden dürfen.
Authentifizierung
WWW-Authenticate-
Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource zuzugreifen.
-
Enthält die Anmeldeinformationen, um einen User-Agent bei 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 Anmeldeinformationen, um einen User-Agent bei einem Proxy-Server zu authentifizieren.
Zwischenspeicherung
Age-
Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache gewesen ist.
Cache-Control-
Direktiven für Zwischenspeichermechanismen in sowohl Anfragen als auch Antworten.
Clear-Site-Data-
Löscht Browserdaten (z. B. Cookies, Speicher, Cache), die mit der anfragenden Website verbunden sind.
Expires-
Das Datum/Uhrzeit, nach dem die Antwort als veraltet gilt.
No-Vary-SearchExperimentell-
Gibt einen Satz von Regeln an, die definieren, wie die Abfrageparameter einer URL das Cache-Matching beeinflussen werden. Diese Regeln diktieren, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden sollte.
Bedingte Anfragen
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 leichter zu berechnen. Bedingte Anfragen mitIf-Modified-SinceundIf-Unmodified-Sinceverwenden diesen Wert, um das Verhalten der Anfrage zu ändern. ETag-
Ein eindeutiger String, der die Version der Ressource identifiziert. Bedingte Anfragen mit
If-MatchundIf-None-Matchverwenden 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 (für sichere Anfragen) zu aktualisieren oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine existiert.
If-Modified-Since-
Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur zu übertragen, wenn der Cache veraltet ist.
If-Unmodified-Since-
Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies gewährleistet die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen oder um ein optimistisches Nebenläufigkeitskontrollsystem bei der Änderung bestehender Dokumente zu implementieren.
Vary-
Bestimmt, wie zugeordnete Anforderungsheader übereinstimmen sollen, um festzustellen, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.
Verbindungsverwaltung
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 zur Inhaltsaushandlung.
Accept-
Informiert den Server über die Typen von Daten, die zurückgesendet werden können.
Accept-Encoding-
Der Kodierungsalgorithmus, normalerweise ein Kompressionsalgorithmus, 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 in der Kontrolle des Benutzers: Der Server sollte immer darauf achten, die explizite Wahl des Benutzers (wie die Auswahl einer Sprache aus einer Dropdown-Liste) nicht zu überschreiben.
Accept-Patch-
Ein Antwortheader für Anforderungsinhaltsverhandlung, der darauf hinweist, welchen Medientyp der Server in einer
PATCH-Anfrage verstehen kann. Accept-Post-
Ein Antwortheader für Anforderungsinhaltsverhandlung, der darauf hinweist, 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-
Gibt bei der Verwendung von
TRACEdie maximale Anzahl von Hops an, die die Anfrage machen kann, bevor sie an den Absender zurückgesendet wird.
Cookies
-
Enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem
Set-CookieHeader gesendet wurden. -
Sendet Cookies vom Server an den User-Agent.
CORS
Für weitere Informationen siehe die CORS-Dokumentation.
Access-Control-Allow-Credentials-
Gibt an, ob die Antwort auf die Anfrage exponiert werden kann, wenn das Anmeldeinformationen-Flag true ist.
Access-Control-Allow-Headers-
Wird als Antwort auf eine vorläufige Anfrage verwendet, um anzuzeigen, 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 vorläufige Anfrage erlaubt sind.
Access-Control-Allow-Origin-
Gibt an, ob die Antwort geteilt werden kann.
Access-Control-Expose-Headers-
Gibt an, welche Header als Teil der Antwort exponiert werden können, indem ihre Namen aufgelistet werden.
Access-Control-Max-Age-
Gibt an, wie lange die Ergebnisse einer vorläufigen Anfrage im Cache gespeichert werden können.
Access-Control-Request-Headers-
Wird beim Ausstellen einer vorläufigen Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden.
Access-Control-Request-Method-
Wird beim Ausstellen einer vorläufigen Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode bei der eigentlichen 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 würden.
Downloads
Content-Disposition-
Gibt an, ob die übertragene Ressource inline angezeigt werden soll (Standardverhalten ohne Header) oder ob sie wie ein Download behandelt werden soll und der Browser ein „Speichern unter“-Dialogfeld anzeigen soll.
Integritätsprüfsummen
Content-DigestExperimentell-
Bietet einen Digest des Oktettstreams, der in einer HTTP-Nachricht (dem Nachrichteninhalt) geframed ist, abhängig von
Content-EncodingundContent-Range. Repr-DigestExperimentell-
Bietet einen Digest der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zum
Content-Digestberücksichtigt der Digest nichtContent-EncodingoderContent-Range. Want-Content-DigestExperimentell-
Äußert den Wunsch nach einem
Content-Digest-Header. Es ist dasContent-Gegenstück zuWant-Repr-Digest. Want-Repr-DigestExperimentell-
Äußert den Wunsch nach einem
Repr-Digest-Header. Es ist dasRepr-Gegenstück zuWant-Content-Digest.
Integritätspolitik
Integrity-Policy-
Stellt sicher, dass alle Ressourcen, die der User-Agent lädt (eines bestimmten Typs), Garantien für Subresource-Integrität haben.
Integrity-Policy-Report-Only-
Berichtet über Ressourcen, die der User-Agent lädt, die gegen Subresource-Integrität verstoßen würden, wenn die Integritätspolitik durchgesetzt würde (mit dem
Integrity-Policy-Header).
Nachrichtentext-Informationen
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 Kompressionsalgorithmus anzugeben.
Content-Language-
Beschreibt die menschliche(n) Sprache(n), die für das Publikum bestimmt sind, sodass ein Benutzer nach seinen eigenen bevorzugten Sprachen differenzieren kann.
Content-Location-
Gibt einen alternativen Standort für die zurückgegebenen Daten an.
Vorlieben
Vorlieben können von Clients in Anfragen gesendet werden, um optionale Verhaltensweisen für Anfragen und Antworten anzugeben. Die Serverantwort kann angeben, ob eine Vorliebe angewendet wurde, in Fällen, in denen es sonst für den Client unklar wäre. Browser haben keine native Handhabung, um Vorlieben über diese Header zu senden; sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.
Prefer-
Gibt Vorlieben für spezifische Serververhalten während der Antragsverarbeitung an. Zum Beispiel kann es minimale Antwortinhalte (
return=minimal) oder asynchrone Verarbeitung (respond-async) anfordern. Der Server bearbeitet die Anfrage normal, wenn der Header nicht unterstützt wird. Preference-Applied-
Informiert den Client, welche Vorlieben, die im
Prefer-Header angegeben sind, vom Server angewendet wurden. Es handelt sich um einen reinen Antwort-Header, um Transparenz über die Verarbeitung von Vorlieben zu bieten.
Proxys
Forwarded-
Enthält Informationen von der dem Client zugewandten Seite von Proxyservern, die verändert oder verloren gehen, wenn ein Proxy auf dem Pfad der Anfrage beteiligt ist.
Via-
Wird von Proxys, sowohl Vorwärts- als auch Rückwärtsproxys, hinzugefügt und kann in den Anforderungs- und den Antwortheadern 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 randomisierten 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 der angegebene ETag oder das angegebene Datum mit der Remote-Ressource übereinstimmt. Wird verwendet, um den Download von zwei Bereichen von inkompatiblen Versionen der Ressource zu verhindern.
Content-Range-
Gibt an, wo in einer vollständigen Nachricht ein Teilstück 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
metaElement mithttp-equiv="refresh"an.
Anfragekontext
From-
Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfragenden User-Agent steuert.
Host-
Gibt den Domainnamen des Servers (für virtuelles Hosting) und optional die TCP-Portnummer an, auf der der Server lauscht.
Referer-
Die Adresse der vorherigen Webseite, von der ein Link zur aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy-
Regelt, welche Referrer-Informationen in dem
Referer-Header mit Anfragen gesendet werden sollen. User-Agent-
Enthält einen charakteristischen String, der es den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfordernden Software-User-Agents zu identifizieren.
Antwortkontext
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 Domänen ein Fenster öffnen/steuern.
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)-
Steuert Ressourcen, die vom User-Agent für eine bestimmte Seite geladen werden dürfen.
Content-Security-Policy-Report-Only-
Ermöglicht Webentwicklern, mit Richtlinien zu experimentieren, indem sie ihre Auswirkungen überwachen, aber nicht erzwingen. Diese Verletzungsberichte bestehen aus JSON-Dokumenten, die über eine HTTP-
POST-Anfrage an die angegebene URI gesendet werden. Expect-CTVeraltet-
Ermöglicht es Websites, sich für die Berichterstattung und Durchsetzung von Certificate Transparency zu entscheiden, um die Verwendung von falsch ausgestellten Zertifikaten für diese Website zu erkennen.
Permissions-Policy-
Bietet einen Mechanismus, um die Verwendung von Browserfunktionen im eigenen Frame einer Website und in von ihr eingebetteten
<iframe>s zu erlauben und zu verweigern. Reporting-EndpointsExperimentell-
Antwortheader, der Website-Besitzern ermöglicht, einen oder mehrere Endpunkte zu spezifizieren, die verwendet werden, um Fehler wie CSP-Verletzungsberichte,
Cross-Origin-Opener-Policy-Berichte oder andere generische Verstöße zu empfangen. 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 ausdrückt und dass er erfolgreich mit der
upgrade-insecure-requests-Direktive umgehen kann. X-Content-Type-Options-
Deaktiviert MIME-Sniffing und zwingt den Browser, den im
Content-Typegegebenen 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-Policy-Datei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domänen hinweg zu handhaben, die ansonsten aufgrund der Same-Origin-Policy eingeschränkt wären. Der
X-Permitted-Cross-Domain-Policies-Header übersteuert solche Policy-Dateien, sodass Clients weiterhin 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 der Anwendung oder ihren Besuchern keinen Nutzen bietet. Deaktivieren Sie diesen Header, um mögliche Schwachstellen nicht offenzulegen.
X-XSS-Protection-
Aktiviert das Filtern von Cross-Site-Scripting.
Fetch-Metadaten-Anforderungsheader
Fetch-Metadaten-Anforderungsheader bieten Informationen über den Kontext, aus dem die Anfrage stammt. Ein Server kann sie verwenden, um Entscheidungen darüber zu treffen, ob eine Anfrage basierend darauf, woher sie kommt und wie die Ressource verwendet wird, erlaubt werden sollte.
Sec-Fetch-Site-
Gibt die Beziehung zwischen dem Ursprung eines Anforderungsinitiators und dem Ziel-Ursprung an. Es handelt sich um einen Structured Header, dessen Wert ein Token mit möglichen Werten
cross-site,same-origin,same-siteundnoneist. Sec-Fetch-Mode-
Gibt dem Server den Modus der Anfrage an. Es handelt sich um einen Structured Header, dessen Wert ein Token mit möglichen Werten
cors,navigate,no-cors,same-originundwebsocketist. Sec-Fetch-User-
Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktivierung ausgelöst wurde oder nicht. Es handelt sich um einen Structured Header, dessen Wert ein Boolescher Wert ist, sodass mögliche Werte
?0für false und?1für true sind. Sec-Fetch-Dest-
Gibt das Ziel der Anfrage an. Es handelt sich um einen 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,workerundxsltist.
Die folgenden Anforderungsheader sind nicht streng "Fetch-Metadaten-Anforderungsheader", bieten jedoch ähnlich Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten oder die zurückgegebenen Informationen zu modifizieren:
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 nur einen möglichen Wert,
prefetch, das darauf hinweist, dass die Ressource präventiv für eine mögliche zukünftige Navigation abgerufen wird. -
Ein Anforderungsheader, der bei einer präventiven Anfrage verwendet wird, um eine Ressource während des Service-Worker-Starts mit
fetch()abzurufen. Der Wert, der mitNavigationPreloadManager.setHeaderValue()festgelegt wird, kann verwendet werden, um einem Server mitzuteilen, dass eine andere Ressource als bei einer normalenfetch()-Operation zurückgegeben werden soll.
Fetch-Speicherzugriffsheader
Diese Header ermöglichen einen verbesserten Workflow für die Storage Access API.
Sec-Fetch-Storage-Access-
Gibt den „Speicherzugriffstatus“ für den aktuellen Fetch-Kontext an, der einer von
none,inactiveoderactivesein wird. Der Server kann mitActivate-Storage-Accessantworten, um den Browser dazu zu bringen, eineinactiveBerechtigung zu aktivieren und die Anfrage erneut auszuführen, oder um eine Ressource mit Zugriff auf ihre Third-Party-Cookies zu laden, wenn der Statusactiveist. Activate-Storage-Access-
Wird als Antwort auf
Sec-Fetch-Storage-Accessverwendet, um anzugeben, dass der Browser eine vorhandene Berechtigung für einen sicheren Zugriff aktivieren und die Anfrage mit Cookies erneut ausführen oder eine Ressource mit Cookie-Zugriff laden kann, wenn bereits eine aktivierte Berechtigung vorliegt.
Server-sent Events
Reporting-Endpoints-
Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser Warnungs- und Fehlerberichte senden soll, wenn die Reporting API verwendet wird.
Report-ToVeraltet Nicht standardisiert-
Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser Warnungs- und Fehlerberichte senden soll, wenn die Reporting API verwendet wird.
Transfer-Codierung
Transfer-Encoding-
Gibt die Form der Kodierung an, die verwendet wurde, um die Ressource sicher an den Benutzer zu übertragen.
TE-
Gibt die Übertragungskodierungen an, die der User-Agent zu akzeptieren bereit ist.
Trailer-
Ermöglicht es dem Sender, am Ende einer chunked Nachricht zusätzliche Felder einzuschließen.
WebSockets
Header, die von der WebSockets API im WebSocket Handshake verwendet werden:
Sec-WebSocket-Accept-
Antwortheader, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung zu upgraden.
Sec-WebSocket-Extensions-
In Anfragen gibt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten gibt es die vom Server aus den Vorlieben des Clients ausgewählte Erweiterung an.
Sec-WebSocket-Key-
Anforderungsheader, der einen Schlüssel enthält, der verifiziert, dass der Client ausdrücklich die Eröffnung eines
WebSocketbeabsichtigt. Sec-WebSocket-Protocol-
In Anfragen gibt dieser Header die vom Client unterstützten Subprotokolle in bevorzugter Reihenfolge an. In Antworten gibt es das vom Server aus den Vorlieben 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 es nur gesendet, wenn die angeforderte Protokollversion vom Server nicht unterstützt wird, und listet die Versionen auf, die der Server unterstützt.
Sonstige
Alt-Svc-
Wird verwendet, um alternative Möglichkeiten aufzulisten, um diesen Dienst zu erreichen.
Alt-Used-
Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.
Date-
Enthält das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde.
Link-
Dieses Entity-Header-Feld bietet ein Mittel zur Serialisierung eines oder mehrerer Links in HTTP-Headern. Es ist semantisch äquivalent zum HTML-
<link>-Element. Retry-After-
Gibt an, wie lange der User-Agent warten sollte, bevor eine Folgeanfrage gestellt wird.
Server-Timing-
Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.
Service-Worker-
Wird bei Fetches für die Skriptressource eines Service Workers eingeschlossen. Dieser Header hilft Administratoren, Anfragen von Serviceworker-Skripts zu protokollieren, um sie zu überwachen.
Service-Worker-Allowed-
Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header in der Antwort des Service Worker Skripts enthalten ist.
SourceMap-
Verlinkt auf eine Quellenkarte, damit Debugger durch den ursprünglichen Quellcode statt durch den generierten oder transformierten Code schrittweise durchgehen 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) zu aktualisieren. Beispielsweise kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 zu aktualisieren oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket.
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 anzuzeigen, oder in einer Antwort, wenn der Server sich dazu entscheidet, die Anfrage neu zu priorisieren.
Experimentelle Header
>Attributionsberichterstattungsheader
Die Attribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen — zum Beispiel, wenn ein Benutzer auf eine Anzeige auf einer Website klickt und dann auf der Website des Anbieters den Artikel kauft — und dann Berichte über diese Konversionen abzurufen. Sie tut dies ohne auf Cookies von Drittanbietern angewiesen zu sein, sondern stützt sich auf verschiedene Header, um Quellen und Auslöser zu registrieren, die angeglichen werden, um eine Konversion anzuzeigen.
Attribution-Reporting-Eligible-
Wird verwendet, um anzuzeigen, dass die Antwort, die zur aktuellen Anfrage gehört, berechtigt ist, an der Attributionsberichterstattung 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 Sammlung von Anforderungsheadern, die nützliche Informationen über den Client wie den Gerätetyp und die Netzbedingungen bereitstellen und es Servern ermöglichen, zu optimieren, was für diese Bedingungen gedient wird.
Server fordern proaktiv die Client-Hinweis-Header an, die sie vom Client interessieren, 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 mit dem Headerfeld
Accept-CHoder einem äquivalenten HTML-<meta>-Element mit dem Attributhttp-equivankündigen. Critical-CHExperimentell-
Server verwenden
Critical-CHzusammen mitAccept-CH, um anzugeben, dass angenommene Client-Hinweise auch kritische Client-Hinweise sind.
Die verschiedenen Kategorien von Client-Hinweisen sind unten aufgeführt.
User-Agent-Client-Hinweise
Die UA-Client-Hinweise sind Anforderungsheader, die Informationen über den User-Agent, die Plattform/Architektur, auf der er läuft, und Benutzerpräferenzen, die auf dem User-Agent oder der Plattform gesetzt sind, bereitstellen:
Sec-CH-UAExperimentell-
Branding und Version des User-Agents.
Sec-CH-UA-ArchExperimentell-
Unterliegende Plattformarchitektur des User-Agents.
Sec-CH-UA-BitnessExperimentell-
Bitrate der zugrundeliegenden CPU-Architektur des User-Agents (zum Beispiel "64"-Bit).
Sec-CH-UA-Form-FactorsExperimentell-
Formfaktoren des User-Agents, die beschreiben, wie Benutzer mit dem User-Agent interagieren.
Sec-CH-UA-Full-VersionVeraltet-
Vollständige Versionszeichenfolge des User-Agents.
Sec-CH-UA-Full-Version-ListExperimentell-
Vollversion für jede Marke in der Markenliste des User-Agents.
Sec-CH-UA-MobileExperimentell-
Der User-Agent läuft auf einem Mobilgerät oder bevorzugt allgemein eine "mobile" Benutzererfahrung.
Sec-CH-UA-ModelExperimentell-
Gerätemodell des User-Agents.
Sec-CH-UA-PlatformExperimentell-
Betriebssystem/Plattform des User-Agents.
Sec-CH-UA-Platform-VersionExperimentell-
Betriebssystemversion des User-Agents.
Sec-CH-UA-WoW64Experimentell-
Ob das User-Agent-Binärprogramm im 32-Bit-Modus auf 64-Bit-Windows läuft.
Sec-CH-Prefers-Color-SchemeExperimentell-
Bevorzugung des Nutzers eines dunklen oder hellen Farbschemas.
Sec-CH-Prefers-Reduced-MotionExperimentell-
Bevorzugung des Nutzers, weniger Animationen und Layoutverschiebungen von Inhalten zu sehen.
Sec-CH-Prefers-Reduced-TransparencyExperimentell-
Anforderungsheader, der die Vorliebe des User-Agents für reduzierte Transparenz angibt.
Hinweis: User-Agent-Client-Hinweise sind in abgezirkelten Frames nicht verfügbar, da sie auf Berechtigungspolitik-Delegation beruhen, die verwendet werden könnte, um Daten zu leaken.
Geräte-Client-Hinweise
Sec-CH-Device-MemoryExperimentell-
Ungefähre Menge des verfügbaren RAM-Speichers des Clients. Dies ist Teil der Gerätespeicher-API.
Sec-CH-DPRExperimentell-
Anforderungsheader, der das Pixeldichteverhältnis des Client-Geräts angibt (die Anzahl physikalischer Gerätepixel für jedes CSS-Pixel).
Sec-CH-Viewport-HeightExperimentell-
Anforderungsheader, der die Layoutviewporthöhe des Clients in CSS-Pixeln angibt.
Sec-CH-Viewport-WidthExperimentell-
Anforderungsheader, der die Layoutviewportbreite des Clients in CSS-Pixeln angibt.
Veraltete Geräte-Client-Hinweise
Device-MemoryVeraltet Nicht standardisiert-
Umbenannt in
Sec-CH-Device-Memory DPRVeraltet Nicht standardisiert-
Umbenannt in
Sec-CH-DPR Viewport-WidthVeraltet Nicht standardisiert-
Umbenannt in
Sec-CH-Viewport-Width WidthVeraltet Nicht standardisiert-
Umbenannt in
Sec-CH-Width
Netzwerk-Client-Hinweise
Netzwerk-Client-Hinweise ermöglichen es einem Server, zu wählen, welche Informationen basierend auf der Benutzerwahl und der Netzwerkbandbreite und -latenz gesendet werden.
DownlinkExperimentell-
Ungefähr die Bandbreite der Verbindung des Clients zum Server, in Mbps. Dies ist Teil der Netzwerkinformationen-API.
ECTExperimentell-
Der effektive Verbindungstyp („Netzwerkprofil“), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Netzwerkinformationen-API.
RTTExperimentell-
Anwendungsinstanz-Rundlaufzeit (RTT) in Millisekunden, die die Serverbearbeitungszeit einschließt. Dies ist Teil der Netzwerkinformationen-API.
Save-DataExperimentell-
Ein String
on, der die Präferenz des User-Agents für reduzierte Datennutzung anzeigt.
Kompressionswörterbuch-Transport
Kompressionswörterbuch-Transport ist eine Möglichkeit, ein gemeinsames Kompressionswörterbuch zu verwenden, um die Transportgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch in Brotli-Kompression oder Zstandard-Kompression zu verwenden.
Available-DictionaryExperimentell-
Ein Browser kann diesen Anforderungsheader verwenden, um das beste verfügbare Wörterbuch anzugeben, das der Server für die Kompression verwenden kann.
Dictionary-IDExperimentell-
Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource hat und der Server eine
idfü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-idimDictionary-ID-Header. Use-As-DictionaryExperimentell-
Listet die übereinstimmenden Kriterien auf, für die das Wörterbuch bei zukünftigen Anfragen verwendet werden kann.
Datenschutz
DNTVeraltet Nicht standardisiert-
Anforderungsheader, der die Tracking-Präferenz des Nutzers anzeigt (Do Not Track). Veraltet zugunsten von Global Privacy Control (GPC), das Servern über den
Sec-GPC-Header mitgeteilt wird und Clients übernavigator.globalPrivacyControlzugänglich ist. TkVeraltet Nicht standardisiert-
Antwortheader, der den Tracking-Status angibt, der für die entsprechende Anfrage gilt. Wird in Verbindung mit DNT verwendet.
Sec-GPCNicht standardisiert Experimentell-
Gibt an, ob der Nutzer einer Website oder einem Dienst zustimmt, persönliche Informationen an Dritte zu verkaufen oder mit ihnen zu teilen.
Sicherheit
Origin-Agent-ClusterExperimentell-
Antwortheader, der verwendet wird, um anzugeben, dass das verbundene
Documentin einen herkunftsbezogenen Agenten-Cluster platziert werden soll. Diese Isolation ermöglicht es User-Agents, Implementierungsspezifische Ressourcen für Agenten-Cluster wie Prozesse oder Threads effizienter zuzuweisen.
Server-sent Events
NELExperimentell-
Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Berichterstattungsrichtlinie für Netzwerkfehler zu deklarieren.
Themen-API
Die Themen-API bietet einen Mechanismus für Entwickler, um Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. Weitere Informationen finden Sie in der Temen-API Dokumentation.
Observe-Browsing-TopicsExperimentell Nicht standardisiert-
Antwortheader, der verwendet wird, um Themen von Interesse zu markieren, die aus der URL der aufrufenden Website abgeleitet wurden, weil sie in der Antwort auf eine Anfrage beobachtet wurden, die von einer Funktion ausgelöst wurde, die die Themen-API aktiviert.
Sec-Browsing-TopicsExperimentell Nicht standardisiert-
Anforderungsheader, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Anzeigenplattform verwendet werden, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.
Sonstiges
Accept-SignatureExperimentell-
Ein Client kann das
Accept-Signature-Headerfeld senden, um die Absicht anzugeben, von allen verfügbaren Signaturen zu profitieren und um anzugeben, welche Arten von Signaturen es unterstützt. Early-DataExperimentell-
Gibt an, dass die Anfrage in TLS früheren Daten übertragen wurde.
Idempotency-KeyExperimentell-
Bietet einen eindeutigen Schlüssel für
POST- undPATCH-Anfragen und ermöglicht es ihnen, idempotent zu sein. Set-LoginExperimentell-
Antwortheader, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, d.h. ob Benutzer beim IdP im aktuellen Browser angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM-API verwendet.
SignatureExperimentell-
Das
Signature-Headerfeld übermittelt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität der Signatur bestimmt und diese Signatur aktualisiert wird. Signed-HeadersExperimentell-
Das
Signed-Headers-Headerfeld identifiziert eine geordnete Liste von Antwortheaderfeldern, die in eine Signatur aufgenommen werden sollen. Speculation-RulesExperimentell-
Bietet eine Liste von URLs, die auf Textressourcen zeigen, die Spekulationsregel JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregelsatz des Dokuments hinzugefügt.
-
Enthält einen oder mehrere Tag-Werte aus den Spekulationsregeln, die zur Spekulation führten, damit ein Server identifizieren kann, welche Regel(n) eine Spekulation verursachten und möglicherweise blockiert werden könnten.
Supports-Loading-ModeExperimentell-
Wird von einem Navigationstarget gesetzt, um die Verwendung verschiedener risikoreicherer Lademodi zu aktivieren. Beispielsweise erfordert das Prerendering innerhalb eines cross-origin, same-site Vorladens einen
Supports-Loading-Mode-Wert voncredentialed-prerender.
Nichtstandardisierte Header
X-Forwarded-ForNicht standardisiert-
Identifiziert die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder einen Lastverteiler mit einem Webserver verbunden ist.
X-Forwarded-HostNicht standardisiert-
Identifiziert den ursprünglichen Host, den ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Lastverteiler herzustellen.
X-Forwarded-ProtoNicht standardisiert-
Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Lastverteiler herzustellen.
X-DNS-Prefetch-ControlNicht standardisiert-
Steuert das DNS-Vorabrufen, eine Funktion, bei der Browser proaktiv die Domänennamenauflösung sowohl für Links, die der Benutzer möglicherweise auswählt, als auch für URLs für Elemente, die im Dokument referenziert werden, einschließlich Bildern, CSS, JavaScript usw., durchführen.
X-Robots-TagNicht standardisiert-
Der
X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite in öffentlichen Suchmaschinenergebnissen indexiert werden soll. Der Header ist äquivalent zu<meta name="robots">-Elementen.
Veraltete Header
PragmaVeraltet-
Implementierungsspezifischer Header, der an verschiedenen Stellen entlang der Anfrage-Antwort-Kette verschiedene Effekte haben kann. Wird zur Rückwärtskompatibilität mit HTTP/1.0-Caches verwendet, bei denen der
Cache-Control-Header noch nicht vorhanden ist. WarningVeraltet-
Allgemeine Warninformationen über mögliche Probleme.