HTTP-Header
HTTP-Header ermöglichen es dem Client und dem Server, mit einer Nachricht in einer Anfrage oder Antwort zusätzliche Informationen zu übermitteln.
In HTTP/1.X ist ein Header ein Name ohne Beachtung der Groß- und Kleinschreibung, gefolgt von einem Doppelpunkt, anschließend optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel: Allow: POST).
In HTTP/2 und höher werden Header bei der Anzeige in Entwicklerwerkzeugen kleingeschrieben dargestellt (accept: */*) und für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt vorangestellt (:status: 200).
Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.
Benutzerdefinierte proprietäre Header wurden historisch mit dem Präfix X- verwendet, aber diese Konvention wurde 2012 aufgrund der Unannehmlichkeiten, die sie verursachte, wenn nicht standardisierte Felder in RFC 6648 standardisiert wurden, als veraltet eingestuft; weitere sind in der IANA HTTP Field Name Registry aufgeführt, deren ursprünglicher Inhalt in RFC 4229 definiert wurde.
Die IANA-Registry führt Header auf, einschließlich Informationen zu ihrem Status.
Header können anhand ihres Kontexts gruppiert werden:
- Anfrage-Header
-
Enthalten weitere Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.
- Antwort-Header
-
Enthalten zusätzliche Informationen über die Antwort, etwa ihren Ort oder den Server, der sie bereitstellt.
- Repräsentations-Header
-
Enthalten Informationen über den Body der Ressource, etwa ihren MIME-Typ oder die angewendete Kodierung/Komprimierung.
- Payload-Header
-
Enthalten repräsentationsunabhängige Informationen über Payload-Daten, einschließlich der Inhaltslänge und der für den Transport verwendeten Kodierung.
Header können auch danach gruppiert werden, wie Proxys sie behandeln:
- End-to-End-Header
-
Diese Header müssen an den endgültigen Empfänger der Nachricht übertragen werden: den Server bei einer Anfrage oder den Client bei einer 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 Verbindung auf Transportebene relevant und dürfen nicht von Proxys weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mithilfe des Headers
Connectiongesetzt werden können.
Authentifizierung
WWW-Authenticate-
Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource verwendet werden soll.
-
Enthält die Zugangsdaten zur Authentifizierung eines User-Agents gegenüber einem Server.
Proxy-Authenticate-
Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource hinter einem Proxyserver verwendet werden soll.
-
Enthält die Zugangsdaten zur Authentifizierung eines User-Agents gegenüber einem Proxyserver.
Caching
Age-
Die Zeit in Sekunden, die sich das Objekt in einem Proxy-Cache befunden hat.
Cache-Control-
Direktiven für Caching-Mechanismen sowohl in Anfragen als auch in Antworten.
Clear-Site-Data-
Löscht Browsing-Daten (z. B. Cookies, Speicher, Cache), die mit der anfragenden Website verknüpft sind.
Expires-
Das Datum bzw. die Uhrzeit, nach dem bzw. der die Antwort als veraltet gilt.
No-Vary-Search-
Gibt eine Reihe von Regeln an, die definieren, wie die Abfrageparameter einer URL den Cache-Abgleich beeinflussen. Diese Regeln legen fest, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.
Bedingungen
Last-Modified-
Das Datum der letzten Änderung der Ressource, das zum Vergleich mehrerer Versionen derselben Ressource verwendet wird. Es ist weniger genau als
ETag, in einigen Umgebungen jedoch einfacher zu berechnen. Bedingte Anfragen, dieIf-Modified-SinceundIf-Unmodified-Sinceverwenden, nutzen diesen Wert, um das Verhalten der Anfrage zu ändern. ETag-
Eine eindeutige Zeichenfolge, die die Version der Ressource identifiziert. Bedingte Anfragen, die
If-MatchundIf-None-Matchverwenden, 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 mit keinem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (bei sicheren Anfragen) oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine existiert.
If-Modified-Since-
Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur zu übertragen, wenn der Cache nicht mehr aktuell 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 vorherigen Fragmenten sicher oder implementiert beim Ändern vorhandener Dokumente ein System zur optimistischen Nebenläufigkeitssteuerung.
Vary-
Legt fest, wie Anfrage-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Origin-Server anzufordern.
Verbindungsverwaltung
Connection-
Steuert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion geöffnet bleibt.
Keep-Alive-
Steuert, wie lange eine persistente Verbindung geöffnet 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, üblicherweise ein Komprimierungsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.
Accept-Language-
Informiert den Server über die natürliche Sprache, die der Server voraussichtlich zurücksenden soll. Dies ist ein Hinweis und liegt nicht unbedingt vollständig unter der Kontrolle des Benutzers: Der Server sollte stets darauf achten, eine ausdrückliche Auswahl des Benutzers nicht zu überschreiben, beispielsweise die Auswahl einer Sprache aus einer Dropdown-Liste.
Accept-Patch-
Ein Antwort-Header für Anfrage-Inhaltsaushandlung, der ankündigt, welchen Medientyp der Server in einer
PATCH-Anfrage verstehen kann. Accept-Post-
Ein Antwort-Header für Anfrage-Inhaltsaushandlung, der ankündigt, welchen Medientyp der Server in einer
POST-Anfrage verstehen kann.
Steuerung
Expect-
Gibt Erwartungen an, die vom Server erfüllt werden müssen, damit die Anfrage ordnungsgemäß verarbeitet werden kann.
Max-Forwards-
Gibt bei Verwendung von
TRACEdie maximale Anzahl von Hops an, die die Anfrage durchlaufen darf, bevor sie an den Absender zurückgespiegelt wird.
Cookies
-
Enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem Header
Set-Cookiegesendet wurden. -
Sendet Cookies vom Server an den User-Agent.
CORS
Weitere Informationen finden Sie in der CORS-Dokumentation.
Access-Control-Allow-Credentials-
Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Credentials-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 beim Zugriff auf die Ressource als Antwort auf eine Preflight-Anfrage erlaubten Methoden an.
Access-Control-Allow-Origin-
Gibt an, ob die Antwort geteilt werden kann.
Access-Control-Expose-Headers-
Gibt durch Auflisten ihrer Namen an, welche Header als Teil der Antwort offengelegt werden können.
Access-Control-Max-Age-
Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage zwischengespeichert werden können.
Access-Control-Request-Headers-
Wird beim Ausstellen einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden.
Access-Control-Request-Method-
Wird beim Ausstellen einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Methode bei der eigentlichen Anfrage verwendet wird.
Origin-
Gibt an, woher ein Fetch stammt.
Timing-Allow-Origin-
Gibt Origins an, die Werte von Attributen sehen dürfen, die über Funktionen der Resource Timing API abgerufen wurden und aufgrund von Cross-Origin-Einschränkungen andernfalls 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 einen „Speichern unter“-Dialog anzeigen soll.
Integritäts-Digests
Content-Digest-
Stellt einen Digest des in einer HTTP-Nachricht gerahmten Oktettstroms bereit (des Nachrichteninhalts), abhängig von
Content-EncodingundContent-Range. Repr-Digest-
Stellt einen Digest der ausgewählten Repräsentation der Zielressource vor der Übertragung bereit. Anders als
Content-Digestberücksichtigt der Digest wederContent-EncodingnochContent-Range. Want-Content-Digest-
Äußert den Wunsch nach einem Header
Content-Digest. Er ist dasContent--Analogon vonWant-Repr-Digest. Want-Repr-Digest-
Äußert den Wunsch nach einem Header
Repr-Digest. Er ist dasRepr--Analogon vonWant-Content-Digest.
Integritätsrichtlinie
Integrity-Policy-
Stellt sicher, dass alle Ressourcen, die der User-Agent lädt (eines bestimmten Typs), Subresource-Integrity-Garantien haben.
Integrity-Policy-Report-Only-
Meldet Ressourcen, die der User-Agent lädt und die gegen Subresource-Integrity-Garantien verstoßen würden, wenn die Integritätsrichtlinie durchgesetzt würde (mithilfe des Headers
Integrity-Policy).
Informationen zum Nachrichten-Body
Content-Length-
Die Größe der Ressource als dezimale Anzahl von Bytes.
Content-Type-
Gibt den Medientyp der Ressource an.
Content-Encoding-
Wird verwendet, um den Komprimierungsalgorithmus anzugeben.
Content-Language-
Beschreibt die für die Zielgruppe bestimmte(n) natürliche(n) Sprache(n), sodass ein Benutzer nach seiner eigenen bevorzugten Sprache unterscheiden kann.
Content-Location-
Gibt einen alternativen Ort für die zurückgegebenen Daten an.
Nachrichtensignaturen
Accept-Signature-
Der Header
Accept-Signaturefordert eine signierte Antwort oder nachfolgende Anfrage an und gibt die zu signierenden Komponenten und Signaturparameter an. Signature-
Der Header
Signatureenthält einen oder mehrere beschriftete Signaturwerte. Jede Beschriftung entspricht einem Eintrag inSignature-Input. Signature-Input-
Der Header
Signature-Inputidentifiziert die geordnete Liste der von jeder Signatur abgedeckten Nachrichtenkomponenten sowie deren Metadaten, beispielsweise Erstellungszeit und Schlüsselkennung.
Hinweis:
Diese Definitionen folgen RFC 9421. Der Entwurf zu Signed HTTP Exchanges (SXG) definiert ebenfalls Accept-Signature und Signature mit inkompatibler Semantik sowie einen eigenen Header Signed-Headers. Die einzige Browserimplementierung von SXG, Chromium, unterstützt diese jedoch nicht als HTTP-Header.
Präferenzen
Clients können Präferenzen in Anfragen senden, um optionale Verhaltensweisen für Anfragen und Antworten anzugeben. Die Serverantwort kann angeben, ob eine Präferenz angewendet wird, wenn dies andernfalls für den Client mehrdeutig wäre. Browser bieten keine native Unterstützung für das Senden von Präferenzen über diese Header; sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.
Prefer-
Gibt Präferenzen für bestimmte Serververhaltensweisen während der Anfrageverarbeitung an. Beispielsweise kann minimaler Antwortinhalt (
return=minimal) oder asynchrone Verarbeitung (respond-async) angefordert werden. Der Server verarbeitet die Anfrage normal, wenn der Header nicht unterstützt wird. Preference-Applied-
Informiert den Client darüber, welche im Header
Preferangegebenen Präferenzen vom Server angewendet wurden. Dies ist ein Header nur für Antworten, der Transparenz über die Behandlung von Präferenzen bietet.
Proxys
Forwarded-
Enthält Informationen von der clientseitigen Seite von Proxyservern, die geändert werden oder verloren gehen, wenn ein Proxy am Pfad der Anfrage beteiligt ist.
Via-
Wird von Proxys hinzugefügt, sowohl von Forward- als auch von Reverse-Proxys, und kann in Anfrage-Headern und Antwort-Headern erscheinen.
Bereichsanfragen
HTTP-Bereichsanfragen ermöglichen dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind für Anwendungen wie Mediaplayer nützlich, die Direktzugriff unterstützen, für Datenwerkzeuge, die wissen, dass sie nur einen Teil einer großen Datei benötigen, sowie für Download-Manager, die Benutzern das Anhalten und Fortsetzen eines Downloads ermöglichen.
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 zweier Bereiche aus inkompatiblen Versionen der Ressource zu verhindern.
Content-Range-
Gibt an, an welcher Stelle in einer vollständigen Body-Nachricht eine Teilnachricht gehört.
Weiterleitungen
Location-
Gibt die URL an, zu der eine Seite weitergeleitet werden soll.
Refresh-
Weist den Browser an, die Seite neu zu laden oder zu einer anderen weiterzuleiten. Akzeptiert denselben Wert wie das Element
metamithttp-equiv="refresh".
Anfragekontext
From-
Enthält eine Internet-E-Mail-Adresse eines menschlichen Benutzers, 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 aus ein Link zur aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy-
Legt fest, welche Referrer-Informationen, die im Header
Referergesendet werden, in ausgeführten Anfragen enthalten sein sollen. User-Agent-
Enthält eine charakteristische Zeichenfolge, die es Netzwerkprotokoll-Gegenstellen ermöglicht, Anwendungstyp, Betriebssystem, Softwareanbieter oder Softwareversion des anfragenden Software-User-Agents zu identifizieren.
Antwortkontext
Sicherheit
Cross-Origin-Embedder-Policy(COEP)-
Ermöglicht einem Server, eine Embedder-Richtlinie für ein bestimmtes Dokument zu deklarieren.
Cross-Origin-Opener-Policy(COOP)-
Verhindert, dass andere Domains ein Fenster öffnen oder steuern.
Cross-Origin-Resource-Policy(CORP)-
Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch den erklärenden Artikel zu CORP.
Content-Security-Policy(CSP)-
Steuert, welche Ressourcen der User-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only-
Ermöglicht Webentwicklern, mit Richtlinien zu experimentieren, indem deren Auswirkungen überwacht, aber nicht durchgesetzt werden. Diese Verletzungsberichte bestehen aus JSON-Dokumenten, die über eine HTTP-
POST-Anfrage an die angegebene URI gesendet werden. Expect-CT-
Ermöglicht Websites die Teilnahme an der Meldung und Durchsetzung von Certificate Transparency, um die Verwendung falsch ausgestellter Zertifikate für diese Website zu erkennen.
Permissions-Policy-
Bietet einen Mechanismus zum Erlauben und Verweigern der Nutzung von Browserfunktionen im eigenen Frame einer Website sowie in eingebetteten
<iframe>s. Reporting-Endpoints-
Antwort-Header, der Websiteinhabern erlaubt, einen oder mehrere Endpunkte anzugeben, die zum Empfang von Fehlern wie CSP-Verletzungsberichten,
Cross-Origin-Opener-Policy-Berichten oder anderen allgemeinen Verletzungen verwendet werden. Strict-Transport-Security(HSTS)-
Erzwingt Kommunikation über HTTPS statt über 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 angibt, dass dieser die Direktive
upgrade-insecure-requestserfolgreich verarbeiten kann. X-Content-Type-Options-
Deaktiviert MIME-Sniffing und zwingt den Browser, den in
Content-Typeangegebenen Typ zu verwenden. X-Frame-Options(XFO)-
Gibt an, ob ein Browser eine Seite in einem
<frame>,<iframe>,<embed>oder<object>rendern darf. X-Permitted-Cross-Domain-Policies-
Eine Cross-Domain-Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domains hinweg zu verarbeiten, die andernfalls aufgrund der Same-Origin-Policy eingeschränkt wären. Der Header
X-Permitted-Cross-Domain-Policiesüberschreibt solche Richtliniendateien, sodass Clients unerwünschte Anfragen weiterhin blockieren. X-Powered-By-
Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen darüber, ohne der Anwendung oder ihren Besuchern einen Nutzen zu bieten. Entfernen Sie diesen Header, um die Offenlegung potenzieller Sicherheitslücken zu vermeiden.
X-XSS-Protection-
Aktiviert Cross-Site-Scripting-Filterung.
Fetch-Metadaten-Anfrage-Header
Fetch-Metadaten-Anfrage-Header stellen Informationen über den Kontext bereit, aus dem die Anfrage stammt. Ein Server kann sie verwenden, um Entscheidungen darüber zu treffen, ob eine Anfrage erlaubt werden soll, basierend darauf, woher die Anfrage stammt und wie die Ressource verwendet wird.
Sec-Fetch-Site-
Gibt die Beziehung zwischen der Origin des Anfrageinitiators und der Origin des Ziels an. Es ist ein Structured Header, dessen Wert ein Token mit den möglichen Werten
cross-site,same-origin,same-siteundnoneist. Sec-Fetch-Mode-
Gibt einem Server den Modus der Anfrage an. Es ist ein Structured Header, dessen Wert ein Token mit den möglichen Werten
cors,navigate,no-cors,same-originundwebsocketist. Sec-Fetch-User-
Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktivierung ausgelöst wurde. Es ist ein Structured Header, dessen Wert ein boolescher Wert ist; mögliche Werte sind daher
?0für falsch und?1für wahr. Sec-Fetch-Dest-
Gibt das Ziel der Anfrage an. Es ist ein Structured Header, dessen Wert ein Token mit den möglichen Werten
audio,audioworklet,document,embed,empty,font,image,manifest,object,paintworklet,report,script,serviceworker,sharedworker,style,track,video,workerundxsltist.
Die folgenden Anfrage-Header sind nicht streng genommen „Fetch-Metadaten-Anfrage-Header“, stellen jedoch ähnlich Informationen über den Kontext bereit, in dem eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten oder die zurückgegebenen Informationen zu ändern:
Sec-Purpose-
Gibt den Zweck der Anfrage an, wenn dieser Zweck nicht die unmittelbare Verwendung durch den User-Agent ist. Der Header hat derzeit einen möglichen Wert,
prefetch, der angibt, dass die Ressource vorsorglich für eine mögliche zukünftige Navigation abgerufen wird. -
Ein Anfrage-Header, der in einer vorsorglichen Anfrage gesendet wird, um während des Starts eines Service Workers eine Ressource mit
fetch()abzurufen. Der Wert, der mitNavigationPreloadManager.setHeaderValue()gesetzt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource als bei einem normalenfetch()-Vorgang zurückgegeben werden soll.
Fetch-Speicherzugriffs-Header
Diese Header ermöglichen einen erweiterten Workflow für die Storage Access API.
Sec-Fetch-Storage-Access-
Gibt den „Speicherzugriffsstatus“ für den aktuellen Fetch-Kontext an, der entweder
none,inactiveoderactiveist. Der Server kann mitActivate-Storage-Accessantworten, um anzufordern, dass der Browser eine Berechtigung mit dem Statusinactiveaktiviert und die Anfrage wiederholt, oder um eine Ressource mit Zugriff auf ihre Drittanbieter-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 sicheren Zugriff aktivieren und die Anfrage mit Cookies wiederholen kann oder eine Ressource mit Cookie-Zugriff laden kann, wenn bereits eine aktivierte Berechtigung vorhanden ist.
Servergesendete Ereignisse
Reporting-Endpoints-
Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser bei Verwendung der Reporting API Warnungs- und Fehlerberichte senden soll.
Report-To-
Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser bei Verwendung der Reporting API Warnungs- und Fehlerberichte senden soll.
Übertragungskodierung
Transfer-Encoding-
Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.
TE-
Gibt die Übertragungskodierungen an, die der User-Agent akzeptieren möchte.
Trailer-
Ermöglicht dem Absender, am Ende einer in Chunks übertragenen Nachricht zusätzliche Felder einzuschließen.
WebSockets
Header, die von der WebSockets API im WebSocket-Handshake verwendet werden:
Sec-WebSocket-Accept-
Antwort-Header, der angibt, dass der Server bereit ist, auf eine WebSocket-Verbindung hochzustufen.
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-
Anfrage-Header, der einen Schlüssel enthält, der bestätigt, dass der Client ausdrücklich beabsichtigt, einen
WebSocketzu öffnen. Sec-WebSocket-Protocol-
In Anfragen gibt dieser Header die vom Client unterstützten Unterprotokolle in bevorzugter Reihenfolge an. In Antworten gibt er das vom Server aus den Präferenzen des Clients ausgewählte Unterprotokoll an.
Sec-WebSocket-Version-
In Anfragen gibt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn die angeforderte Protokollversion vom Server nicht unterstützt wird, und listet die vom Server unterstützten Versionen auf.
Sonstiges
Alt-Svc-
Wird verwendet, um alternative Wege zum Erreichen dieses Dienstes aufzulisten.
Alt-Used-
Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.
Date-
Enthält das Datum und die Uhrzeit, zu denen die Nachricht erstellt wurde.
Link-
Dieses Entity-Header-Feld bietet eine Möglichkeit, einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML-Element
<link>. Retry-After-
Gibt an, wie lange der User-Agent warten soll, bevor er eine Folgeanfrage stellt.
Server-Timing-
Übermittelt eine oder mehrere Metriken und Beschreibungen für den angegebenen Anfrage-Antwort-Zyklus.
Service-Worker-
Wird in Fetches für die Skriptressource eines Service Workers eingeschlossen. Dieser Header hilft Administratoren dabei, Anfragen für Service-Worker-Skripte zu Überwachungszwecken zu protokollieren.
Service-Worker-Allowed-
Wird verwendet, um die Pfadbeschränkung aufzuheben, indem dieser Header in die Antwort des Service-Worker-Skripts aufgenommen wird.
SourceMap-
Verlinkt auf eine Source Map, sodass Debugger den ursprünglichen Quellcode statt generierten oder transformierten Code schrittweise durchlaufen können.
Upgrade-
Dieser Header (nur HTTP/1.1) kann verwendet werden, um eine bereits aufgebaute Client-Server-Verbindung auf ein anderes Protokoll hochzustufen (über dasselbe Transportprotokoll). Beispielsweise kann ein Client damit eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- bzw. HTTPS-Verbindung auf einen WebSocket hochstufen.
Priority-
Liefert einen Hinweis zur Priorität einer bestimmten Ressourcenanfrage auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzugeben, oder in einer Antwort, wenn der Server die Anfrage neu priorisieren möchte.
Experimentelle Header
>Attribution-Reporting-Header
Die Attribution Reporting API ermöglicht Entwicklern, Conversions zu messen — beispielsweise wenn ein Benutzer auf eine auf einer Website eingebettete Anzeige klickt und das Produkt anschließend auf der Website des Anbieters kauft — und anschließend auf Berichte zu diesen Conversions zuzugreifen. Dies geschieht ohne Abhängigkeit von Drittanbieter-Tracking-Cookies, indem stattdessen verschiedene Header verwendet werden, um Quellen und Trigger zu registrieren, die zur Kennzeichnung einer Conversion abgeglichen werden.
Attribution-Reporting-Eligible-
Wird verwendet, um anzugeben, dass die der aktuellen Anfrage entsprechende Antwort zur Teilnahme am Attribution Reporting berechtigt ist, indem entweder eine Attributionsquelle oder ein Attributions-Trigger registriert wird.
Attribution-Reporting-Register-Source-
Wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen Header
Attribution-Reporting-Eligibleenthielt, und dient zum Registrieren einer Attributionsquelle. Attribution-Reporting-Register-Trigger-
Wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen Header
Attribution-Reporting-Eligibleenthielt, und dient zum Registrieren eines Attributions-Triggers.
Client Hints
HTTP-Client Hints sind eine Gruppe von Anfrage-Headern, die nützliche Informationen über den Client bereitstellen, etwa Gerätetyp und Netzwerkbedingungen, und es Servern ermöglichen, die unter diesen Bedingungen bereitgestellten Inhalte zu optimieren.
Server fordern die Client-Hint-Header, an denen sie interessiert sind, proaktiv mit Accept-CH vom Client an. Der Client kann dann entscheiden, die angeforderten Header in nachfolgenden Anfragen einzuschließen.
Accept-CH-
Server können Unterstützung für Client Hints mit dem Headerfeld
Accept-CHoder einem äquivalenten HTML-Element<meta>mit dem Attributhttp-equivankündigen. Critical-CH-
Server verwenden
Critical-CHzusammen mitAccept-CH, um anzugeben, dass akzeptierte Client Hints auch kritische Client Hints sind.
Die verschiedenen Kategorien von Client Hints sind unten aufgeführt.
User-Agent-Client-Hints
Die UA-Client-Hints sind Anfrage-Header, die Informationen über den User-Agent, die Plattform/Architektur, auf der er ausgeführt wird, sowie Benutzereinstellungen bereitstellen, die im User-Agent oder auf der Plattform festgelegt sind:
Sec-CH-UA-
Branding und Version des User-Agents.
Sec-CH-UA-Arch-
Zugrunde liegende Plattformarchitektur des User-Agents.
Sec-CH-UA-Bitness-
Bitbreite der zugrunde liegenden CPU-Architektur des User-Agents, beispielsweise „64“ Bit.
Sec-CH-UA-Form-Factors-
Formfaktoren des User-Agents, die beschreiben, wie der Benutzer mit dem User-Agent interagiert.
Sec-CH-UA-Full-Version-
Vollständige Versionszeichenfolge des User-Agents.
Sec-CH-UA-Full-Version-List-
Vollständige Version für jede Marke in der Markenliste des User-Agents.
Sec-CH-UA-Mobile-
Der User-Agent läuft auf einem Mobilgerät oder bevorzugt allgemeiner eine „mobile“ Benutzererfahrung.
Sec-CH-UA-Model-
Gerätemodell des User-Agents.
Sec-CH-UA-Platform-
Zugrunde liegendes Betriebssystem bzw. Plattform des User-Agents.
Sec-CH-UA-Platform-Version-
Version des zugrunde liegenden Betriebssystems des User-Agents.
Sec-CH-UA-WoW64-
Gibt an, ob die Binärdatei des User-Agents unter 64-Bit-Windows im 32-Bit-Modus ausgeführt wird.
Sec-CH-Prefers-Color-Scheme-
Präferenz des Benutzers für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion-
Präferenz des Benutzers, weniger Animationen und Verschiebungen des Inhaltslayouts zu sehen.
Sec-CH-Prefers-Reduced-Transparency-
Anfrage-Header, der die Präferenz des User-Agents für verringerte Transparenz angibt.
Hinweis: User-Agent-Client-Hints sind innerhalb von Fenced Frames nicht verfügbar, da sie auf der Delegierung von Permissions Policy beruhen, die zum Offenlegen von Daten verwendet werden könnte.
Geräte- und responsive Bild-Client-Hints
Sec-CH-Device-Memory-
Ungefähre Menge des verfügbaren RAM-Speichers des Clients. Dies ist Teil der Device Memory API.
Sec-CH-DPR-
Anfrage-Header, der das Gerätepixelverhältnis des Clients bereitstellt, also die Anzahl physischer Gerätepixel pro CSS-Pixel.
Sec-CH-Viewport-Height-
Anfrage-Header, der die Höhe des Layout-Viewports des Clients in CSS-Pixeln bereitstellt.
Sec-CH-Viewport-Width-
Anfrage-Header, der die Breite des Layout-Viewports des Clients in CSS-Pixeln bereitstellt.
Sec-CH-Width-
Anfrage-Header, der die Breite des Bildes in CSS-Pixeln bereitstellt.
Veraltete Geräte- und responsive Bild-Client-Hints
Device-Memory-
Standardisiert als
Sec-CH-Device-Memory DPR-
Standardisiert als
Sec-CH-DPR Viewport-Width-
Standardisiert als
Sec-CH-Viewport-Width Width-
Standardisiert als
Sec-CH-Width
Netzwerk-Client-Hints
Netzwerk-Client-Hints ermöglichen es einem Server, anhand der Benutzerauswahl sowie der Netzwerkbandbreite und -latenz zu bestimmen, welche Informationen gesendet werden.
Downlink-
Ungefähre Bandbreite der Verbindung des Clients zum Server in Mbps. Dies ist Teil der Network Information API.
ECT-
Der effektive Verbindungstyp („Netzwerkprofil“), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.
RTT-
Round-Trip-Time (RTT) der Anwendungsschicht in Millisekunden, einschließlich der Verarbeitungszeit des Servers. Dies ist Teil der Network Information API.
Save-Data-
Eine Zeichenfolge
on, die die Präferenz des User-Agents für einen reduzierten Datenverbrauch angibt.
Compression Dictionary Transport
Compression Dictionary Transport ist eine Methode zur Verwendung eines gemeinsam genutzten Komprimierungswörterbuchs, um die Übertragungsgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch in der Brotli-Komprimierung oder der Zstandard-Komprimierung zu verwenden.
Available-Dictionary-
Ein Browser kann diesen Anfrage-Header verwenden, um das beste verfügbare Wörterbuch anzugeben, das der Server zur Komprimierung verwenden kann.
Dictionary-ID-
Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource verfügbar hat und der Server im Header
Use-As-Dictionaryeineidfür das Wörterbuch bereitgestellt hat. Anfragen für Ressourcen, die das Wörterbuch verwenden können, haben einen HeaderAvailable-Dictionarysowie die vom Server bereitgestellte Wörterbuch-idim HeaderDictionary-ID. Use-As-Dictionary-
Listet die Abgleichkriterien auf, für die das Wörterbuch in zukünftigen Anfragen verwendet werden kann.
Datenschutz
DNT-
Anfrage-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Zugunsten von Global Privacy Control (GPC) veraltet, das Servern über den Header
Sec-GPCmitgeteilt wird und für Clients übernavigator.globalPrivacyControlzugänglich ist. Tk-
Antwort-Header, der den Tracking-Status angibt, der für die entsprechende Anfrage galt. Wird zusammen mit DNT verwendet.
Sec-GPC-
Gibt an, ob der Benutzer damit einverstanden ist, dass eine Website oder ein Dienst seine personenbezogenen Daten an Dritte verkauft oder weitergibt.
Sicherheit
Origin-Agent-Cluster-
Antwort-Header, der verwendet wird, um anzugeben, dass das zugehörige
Documentin einem Origin-gebundenen Agent-Cluster platziert werden soll. Diese Isolation ermöglicht es User-Agents, implementierungsspezifische Ressourcen für Agent-Cluster, beispielsweise Prozesse oder Threads, effizienter zuzuweisen.
Servergesendete Ereignisse
NEL-
Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Richtlinie zur Meldung von Netzwerkfehlern zu deklarieren.
Topics API
Die Topics API stellt Entwicklern einen Mechanismus zur Implementierung von Anwendungsfällen wie interessenbasierter Werbung (IBA) bereit. Weitere Informationen finden Sie in der Dokumentation zur Topics API.
Observe-Browsing-Topics-
Antwort-Header, der verwendet wird, um Interessenthemen, die aus der URL einer aufrufenden Website abgeleitet wurden, als in der Antwort auf eine durch eine Funktion zur Aktivierung der Topics API erzeugte Anfrage beobachtet zu markieren.
Sec-Browsing-Topics-
Anfrage-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet. Diese werden von einer Ad-Tech-Plattform verwendet, um eine personalisierte anzuzeigende Anzeige auszuwählen.
Sonstiges
Early-Data-
Gibt an, dass die Anfrage in TLS Early Data übermittelt wurde.
Idempotency-Key-
Stellt einen eindeutigen Schlüssel für
POST- undPATCH-Anfragen bereit, sodass diese idempotent ausgeführt werden können. Set-Login-
Antwort-Header, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, also ob auf dem aktuellen Browser Benutzer beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM API verwendet.
Speculation-Rules-
Stellt eine Liste von URLs bereit, die auf Textressourcen mit Speculation-Rule-JSON-Definitionen verweisen. 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 Speculation Rules, die zu der Spekulation geführt haben, damit ein Server erkennen kann, welche Regel(n) eine Spekulation verursacht haben, und sie gegebenenfalls blockieren kann.
Supports-Loading-Mode-
Wird von einem Navigationsziel gesetzt, um sich für die Verwendung verschiedener Lademodi mit höherem Risiko anzumelden. Beispielsweise erfordert Cross-Origin-, Same-Site-Prerendering einen Wert von
credentialed-prerenderfürSupports-Loading-Mode.
Nicht standardisierte Header
X-Forwarded-For-
Identifiziert die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder einen Load Balancer eine Verbindung zu einem Webserver herstellt.
X-Forwarded-Host-
Identifiziert den ursprünglich angeforderten Host, den ein Client für die Verbindung zu Ihrem Proxy oder Load Balancer verwendet hat.
X-Forwarded-Proto-
Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client für die Verbindung zu Ihrem Proxy oder Load Balancer verwendet hat.
X-DNS-Prefetch-Control-
Steuert DNS-Prefetching, eine Funktion, mit der Browser proaktiv die Auflösung von Domainnamen sowohl für Links durchführen, denen der Benutzer möglicherweise folgen möchte, als auch für URLs von Elementen, auf die das Dokument verweist, einschließlich Bildern, CSS, JavaScript usw.
X-Robots-Tag-
Der HTTP-Header
X-Robots-Tagwird verwendet, um anzugeben, wie eine Webseite in öffentlichen Suchmaschinenergebnissen indexiert werden soll. Der Header entspricht Elementen<meta name="robots">.
Veraltete Header
Pragma-
Implementierungsspezifischer Header, der überall entlang der Anfrage-Antwort-Kette verschiedene Auswirkungen haben kann. Wird zur Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, bei denen der Header
Cache-Controlnoch nicht vorhanden ist. Warning-
Allgemeine Warninformationen über mögliche Probleme.