HTTP-Header
HTTP-Header ermöglichen es Client und Server, mit einer Anfrage oder Antwort zusätzliche Informationen zu übermitteln.
In HTTP/1.X besteht ein Header aus einem Namen, bei dem die Groß- und Kleinschreibung keine Rolle spielt, einem Doppelpunkt, optionalen Leerzeichen, die ignoriert werden, und schließlich einem Wert (zum Beispiel Allow: POST).
In HTTP/2 und höheren Versionen werden Header in Entwicklerwerkzeugen in Kleinbuchstaben angezeigt (accept: */*). Einer besonderen Gruppe von Pseudo-Headern wird ein Doppelpunkt vorangestellt (:status: 200).
Weitere Informationen zur Syntax der einzelnen Protokollversionen finden Sie auf der Seite HTTP-Nachrichten.
Benutzerdefinierte, proprietäre Header wurden früher mit dem Präfix X- versehen. Diese Konvention wurde jedoch 2012 in RFC 6648 verworfen, weil sie Schwierigkeiten verursachte, wenn nicht standardisierte Felder standardisiert wurden. Weitere Header sind im IANA-Verzeichnis der HTTP-Feldnamen aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde.
Das IANA-Verzeichnis enthält Header einschließlich Informationen zu ihrem Status.
Header lassen sich nach ihrem Kontext gruppieren:
- Anfrage-Header
-
Enthalten weitere Informationen über die abzurufende Ressource oder den Client, der sie anfordert.
- Antwort-Header
-
Enthalten zusätzliche Informationen über die Antwort, etwa ihren Speicherort oder den Server, der sie bereitstellt.
- Repräsentations-Header
-
Enthalten Informationen über den Inhalt der Ressource, etwa ihren MIME-Typ oder die angewendete Kodierung beziehungsweise Komprimierung.
- Payload-Header
-
Enthalten von der Repräsentation unabhängige Informationen über die Payload-Daten, darunter die Inhaltslänge und die für die Übertragung verwendete Kodierung.
Header lassen sich auch danach gruppieren, wie Proxys sie behandeln:
- End-to-End-Header
-
Diese Header müssen an den endgültigen Empfänger der Nachricht übertragen werden: bei einer Anfrage an den Server, bei einer Antwort an den Client. Dazwischengeschaltete 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 über den Header
Connectionnur Hop-by-Hop-Header festgelegt werden dürfen.
Authentifizierung
WWW-Authenticate-
Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource verwendet werden soll.
-
Enthält die Anmeldedaten, mit denen sich ein User-Agent bei einem Server authentifiziert.
Proxy-Authenticate-
Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource hinter einem Proxyserver verwendet werden soll.
-
Enthält die Anmeldedaten, mit denen sich ein User-Agent bei einem Proxyserver authentifiziert.
Caching
Age-
Die Zeit in Sekunden, die sich das Objekt bereits in einem Proxy-Cache befindet.
Cache-Control-
Direktiven für Caching-Mechanismen in Anfragen und Antworten.
Clear-Site-Data-
Löscht Browserdaten (z. B. Cookies, gespeicherte Daten und Cache), die mit der anfragenden Website verknüpft sind.
Expires-
Datum und Uhrzeit, ab denen die Antwort als veraltet gilt.
No-Vary-Search-
Legt Regeln dafür fest, wie sich die Abfrageparameter einer URL auf den Abgleich mit dem Cache auswirken. Diese Regeln bestimmen, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Einträge im Browser-Cache gespeichert werden soll.
Bedingte Anfragen
Last-Modified-
Das Datum der letzten Änderung der Ressource. Es wird verwendet, um verschiedene Versionen derselben Ressource zu vergleichen. Es ist weniger genau als
ETag, lässt sich in manchen Umgebungen aber leichter berechnen. Bedingte Anfragen mitIf-Modified-SinceundIf-Unmodified-Sinceverwenden diesen Wert, um das Verhalten der Anfrage zu ändern. ETag-
Eine eindeutige Zeichenfolge, die 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 mit keinem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (bei sicheren Anfragen) oder um zu verhindern, dass eine neue Ressource hochgeladen wird, wenn bereits eine vorhanden ist.
If-Modified-Since-
Macht die Anfrage bedingt und verlangt, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. So werden Daten nur übertragen, wenn der Cache nicht mehr aktuell ist.
If-Unmodified-Since-
Macht die Anfrage bedingt und verlangt, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies stellt sicher, dass ein neues Fragment eines bestimmten Bereichs mit vorherigen Fragmenten übereinstimmt, oder ermöglicht bei der Änderung bestehender Dokumente eine optimistische Nebenläufigkeitskontrolle.
Vary-
Bestimmt, wie Anfrage-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, statt eine neue vom Ursprungsserver 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 Informationen finden Sie im Artikel zur Inhaltsaushandlung.
Accept-
Teilt dem Server mit, welche Datentypen zurückgesendet werden können.
Accept-Encoding-
Der Kodierungsalgorithmus, in der Regel ein Komprimierungsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.
Accept-Language-
Teilt dem Server mit, in welcher natürlichen Sprache er antworten soll. Dies ist ein Hinweis und liegt nicht unbedingt vollständig in der Kontrolle der Nutzer: Der Server sollte stets darauf achten, eine ausdrückliche Entscheidung der Nutzer, etwa die Auswahl einer Sprache aus einem Dropdown-Menü, nicht zu überschreiben.
Accept-Patch-
Ein Antwort-Header für die Aushandlung von Anfrageinhalten, der angibt, welche Medientypen der Server in einer
PATCH-Anfrage verarbeiten kann. Accept-Post-
Ein Antwort-Header für die Aushandlung von Anfrageinhalten, der angibt, welche Medientypen der Server in einer
POST-Anfrage verarbeiten kann. Accept-Query-
Ein Antwort-Header für die Aushandlung von Anfrageinhalten, der angibt, welche Medientypen der Server in einer
QUERY-Anfrage verarbeiten kann.
Steuerung
Expect-
Gibt Erwartungen an, die der Server erfüllen muss, um die Anfrage ordnungsgemäß zu verarbeiten.
Max-Forwards-
Gibt bei Verwendung von
TRACEdie maximale Anzahl an Hops an, die eine Anfrage durchlaufen darf, bevor sie an den Absender zurückgespiegelt wird.
Cookies
-
Enthält gespeicherte HTTP-Cookies, die der Server zuvor mit dem Header
Set-Cookiegesendet hat. -
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 zugänglich gemacht werden darf, 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 dürfen.
Access-Control-Allow-Methods-
Gibt als Antwort auf eine Preflight-Anfrage an, welche Methoden beim Zugriff auf die Ressource erlaubt sind.
Access-Control-Allow-Origin-
Gibt an, ob die Antwort mit anderen Origins geteilt werden darf.
Access-Control-Expose-Headers-
Führt die Header auf, die als Teil der Antwort zugänglich gemacht werden dürfen.
Access-Control-Max-Age-
Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage zwischengespeichert werden dürfen.
Access-Control-Request-Headers-
Wird beim Senden einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden.
Access-Control-Request-Method-
Wird beim Senden einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode bei der eigentlichen Anfrage verwendet wird.
Origin-
Gibt an, von welchem Origin eine Fetch-Anfrage ausgeht.
Timing-Allow-Origin-
Gibt Origins an, die Werte von Attributen sehen dürfen, die über Funktionen der Resource Timing API abgerufen wurden. Aufgrund von Cross-Origin-Beschränkungen würden diese Werte andernfalls als null gemeldet.
Downloads
Content-Disposition-
Gibt an, ob die übertragene Ressource direkt angezeigt werden soll (das Standardverhalten ohne diesen Header) oder ob sie als 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 enthaltenen Oktettstroms (des Nachrichteninhalts) bereit, der von
Content-EncodingundContent-Rangeabhängt. Repr-Digest-
Stellt einen Digest der ausgewählten Repräsentation der Zielressource vor der Übertragung bereit. Anders als bei
Content-Digestberücksichtigt dieser Digest wederContent-EncodingnochContent-Range. Want-Content-Digest-
Drückt den Wunsch nach einem
Content-Digest-Header aus. Er ist dasContent--Gegenstück zuWant-Repr-Digest. Want-Repr-Digest-
Drückt den Wunsch nach einem
Repr-Digest-Header aus. Er ist dasRepr--Gegenstück zuWant-Content-Digest.
Integritätsrichtlinien
Integrity-Policy-
Stellt sicher, dass alle Ressourcen eines bestimmten Typs, die der User-Agent lädt, Garantien für die Subresource Integrity bieten.
Integrity-Policy-Report-Only-
Meldet vom User-Agent geladene Ressourcen, die Garantien für die Subresource Integrity verletzen würden, wenn die Integritätsrichtlinie durchgesetzt würde (mithilfe des Headers
Integrity-Policy).
Informationen zum Nachrichteninhalt
Content-Length-
Die Größe der Ressource als dezimale Anzahl von Bytes.
Content-Type-
Gibt den Medientyp der Ressource an.
Content-Encoding-
Gibt den Komprimierungsalgorithmus an.
Content-Language-
Beschreibt die natürlichen Sprachen, die für die Zielgruppe vorgesehen sind, damit Nutzer Inhalte anhand ihrer bevorzugten Sprache unterscheiden können.
Content-Location-
Gibt einen alternativen Speicherort für die zurückgegebenen Daten an.
Nachrichtensignaturen
Accept-Signature-
Der Header
Accept-Signaturefordert eine signierte Antwort oder eine nachfolgende signierte Anfrage an und gibt die zu signierenden Komponenten sowie die Signaturparameter an. Signature-
Der Header
Signatureenthält einen oder mehrere mit Labels versehene Signaturwerte. Jedes Label entspricht einem Eintrag inSignature-Input. Signature-Input-
Der Header
Signature-Inputgibt die geordnete Liste der Nachrichtenkomponenten an, die von jeder Signatur abgedeckt werden, sowie deren Metadaten, etwa den Erstellungszeitpunkt und die Schlüsselkennung.
Hinweis:
Diese Definitionen entsprechen RFC 9421. Der Entwurf zu Signed HTTP Exchanges (SXG) definiert Accept-Signature und Signature ebenfalls, allerdings 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 wurde, wenn dies für den Client sonst nicht eindeutig wäre. Browser bieten keine integrierte 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 Verhaltensweisen des Servers bei der Anfrageverarbeitung an. Beispielsweise kann damit ein minimaler Antwortinhalt (
return=minimal) oder eine asynchrone Verarbeitung (respond-async) angefordert werden. Wenn der Header nicht unterstützt wird, verarbeitet der Server die Anfrage wie üblich. Preference-Applied-
Teilt dem Client mit, welche im Header
Preferangegebenen Präferenzen der Server angewendet hat. Dieser ausschließlich in Antworten verwendete Header macht die Behandlung von Präferenzen nachvollziehbar.
Proxys
Bereichsanfragen
HTTP-Bereichsanfragen ermöglichen es dem Client, nur einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind beispielsweise für Mediaplayer mit wahlfreiem Zugriff, Datenwerkzeuge, die nur einen Teil einer großen Datei benötigen, und Download-Manager nützlich, mit denen Nutzer Downloads anhalten und fortsetzen können.
Accept-Ranges-
Gibt an, ob der Server Bereichsanfragen unterstützt und, falls ja, in welcher Einheit der Bereich angegeben werden kann.
Range-
Gibt an, welchen Teil eines Dokuments der Server zurückgeben soll.
If-Range-
Erzeugt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn das angegebene ETag oder Datum mit der entfernten Ressource übereinstimmt. So wird verhindert, dass zwei Bereiche aus inkompatiblen Versionen einer Ressource heruntergeladen werden.
Content-Range-
Gibt an, an welcher Stelle des vollständigen Nachrichteninhalts eine Teilnachricht einzuordnen ist.
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 Seite weiterzuleiten. Verwendet denselben Wert wie das
meta-Element mithttp-equiv="refresh".
Anfragekontext
From-
Enthält die Internet-E-Mail-Adresse einer Person, die den anfragenden User-Agent kontrolliert.
Host-
Gibt den Domainnamen des Servers (für virtuelles Hosting) und optional die Nummer des TCP-Ports an, auf dem der Server Anfragen entgegennimmt.
Referer-
Die Adresse der vorherigen Webseite, von der aus einem Link zur aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy-
Regelt, welche Referrer-Informationen im Header
Refererbei Anfragen enthalten sein sollen. User-Agent-
Enthält eine charakteristische Zeichenfolge, anhand derer die Kommunikationspartner im Netzwerkprotokoll Anwendungstyp, Betriebssystem, Softwareanbieter oder Softwareversion des anfragenden User-Agents erkennen können.
Antwortkontext
Sicherheit
Cross-Origin-Embedder-Policy(COEP)-
Ermöglicht es einem Server, eine Einbettungsrichtlinie für ein bestimmtes Dokument festzulegen.
Cross-Origin-Opener-Policy(COOP)-
Verhindert, dass andere Domains ein Fenster öffnen oder steuern.
Cross-Origin-Resource-Policy(CORP)-
Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch den Artikel zur Erläuterung von 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 es Webentwicklern, mit Richtlinien zu experimentieren, indem sie deren Auswirkungen überwachen, ohne sie durchzusetzen. Die Berichte über Verstöße bestehen aus JSON-Dokumenten, die per HTTP-
POST-Anfrage an die angegebene URI gesendet werden. Expect-CT-
Ermöglicht es Websites, Berichte und die Durchsetzung von Certificate Transparency zu aktivieren, um die Verwendung fehlerhaft ausgestellter Zertifikate für die betreffende Website zu erkennen.
Permissions-Policy-
Bietet einen Mechanismus, um die Verwendung von Browserfunktionen im eigenen Frame einer Website sowie in von ihr eingebetteten
<iframe>s zu erlauben oder zu verweigern. Reporting-Endpoints-
Ein Antwort-Header, über den Websitebetreiber einen oder mehrere Endpunkte angeben können, die Fehler wie Berichte über CSP-Verstöße, Berichte zu
Cross-Origin-Opener-Policyoder andere allgemeine Verstöße empfangen. Strict-Transport-Security(HSTS)-
Erzwingt die Kommunikation über HTTPS statt HTTP.
Upgrade-Insecure-Requests-
Signalisiert dem Server, dass der Client eine verschlüsselte und authentifizierte Antwort bevorzugt und 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>darstellen darf. X-Permitted-Cross-Domain-Policies-
Eine Cross-Domain-Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex unter anderem die Verarbeitung von Daten über Domain-Grenzen hinweg erlauben, die aufgrund der Same-Origin Policy sonst eingeschränkt wäre. Der Header
X-Permitted-Cross-Domain-Policiessetzt solche Richtliniendateien außer Kraft, damit 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 potenzielle Schwachstellen nicht offenzulegen.
X-XSS-Protection-
Aktiviert die Filterung von Cross-Site-Scripting.
Fetch-Metadaten-Anfrage-Header
Fetch-Metadaten-Anfrage-Header liefern Informationen über den Kontext, aus dem eine Anfrage stammt. Ein Server kann anhand der Herkunft der Anfrage und der vorgesehenen Verwendung der Ressource entscheiden, ob er die Anfrage zulässt.
Sec-Fetch-Site-
Gibt die Beziehung zwischen dem Origin des Anfrageauslösers und dem Origin des Ziels an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token mit den 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 strukturierten 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 Nutzeraktivierung ausgelöst wurde. Es handelt sich um einen strukturierten Header mit einem booleschen Wert:
?0steht für falsch und?1für wahr. Sec-Fetch-Dest-
Gibt das Ziel der Anfrage an. Es handelt sich um einen strukturierten 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 streng genommen keine „Fetch-Metadaten-Anfrage-Header“, liefern aber ebenfalls Informationen darüber, wie eine Ressource verwendet wird. Ein Server kann sie nutzen, um sein Caching-Verhalten oder die zurückgegebenen Informationen anzupassen:
Sec-Purpose-
Gibt den Zweck der Anfrage an, wenn die Ressource nicht unmittelbar vom User-Agent verwendet werden soll. Der Header hat derzeit einen möglichen Wert:
prefetchzeigt an, dass die Ressource vorsorglich für eine mögliche spätere Navigation abgerufen wird. -
Ein Anfrage-Header, der bei einer vorsorglichen Anfrage gesendet wird, um während des Starts eines Service Workers eine Ressource mit
fetch()abzurufen. Sein mitNavigationPreloadManager.setHeaderValue()festgelegter Wert kann dem Server mitteilen, dass er eine andere Ressource als bei einer gewöhnlichenfetch()-Operation zurückgeben soll.
Header für den Speicherzugriff beim Fetch
Diese Header ermöglichen einen erweiterten Ablauf für die Storage Access API.
Sec-Fetch-Storage-Access-
Gibt den „Status des Speicherzugriffs“ für den aktuellen Fetch-Kontext an. Dieser ist entweder
none,inactiveoderactive. Der Server kann mitActivate-Storage-Accessantworten, um den Browser aufzufordern, eineinactive-Berechtigung zu aktivieren und die Anfrage zu wiederholen. Ist der Statusactive, kann er den Browser auffordern, die Ressource mit Zugriff auf ihre Drittanbieter-Cookies zu laden. Activate-Storage-Access-
Wird als Antwort auf
Sec-Fetch-Storage-Accessverwendet, um anzugeben, dass der Browser eine bestehende Berechtigung für sicheren Zugriff aktivieren und die Anfrage mit Cookies wiederholen kann. Wenn die Berechtigung bereits aktiviert ist, kann er die Ressource mit Cookie-Zugriff laden.
Server-Sent Events
Reporting-Endpoints-
Antwort-Header zur Angabe von Server-Endpunkten, an die der Browser bei Verwendung der Reporting API Warn- und Fehlerberichte senden soll.
Report-To-
Antwort-Header zur Angabe von Server-Endpunkten, an die der Browser bei Verwendung der Reporting API Warn- und Fehlerberichte senden soll.
Übertragungskodierung
Transfer-Encoding-
Gibt die Kodierungsform an, mit der die Ressource sicher an den Nutzer übertragen wird.
TE-
Gibt die Übertragungskodierungen an, die der User-Agent akzeptiert.
Trailer-
Ermöglicht es dem Absender, am Ende einer in Chunks übertragenen Nachricht zusätzliche Felder anzufügen.
WebSockets
Header, die von der WebSockets API beim WebSocket-Handshake verwendet werden:
Sec-WebSocket-Accept-
Antwort-Header, der angibt, dass der Server bereit ist, auf eine WebSocket-Verbindung umzuschalten.
Sec-WebSocket-Extensions-
In Anfragen gibt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten gibt er die Erweiterung an, die der Server aus den Präferenzen des Clients ausgewählt hat.
Sec-WebSocket-Key-
Anfrage-Header mit einem Schlüssel, der bestätigt, dass der Client ausdrücklich einen
WebSocketöffnen möchte. Sec-WebSocket-Protocol-
In Anfragen gibt dieser Header die vom Client unterstützten Unterprotokolle in bevorzugter Reihenfolge an. In Antworten gibt er das Unterprotokoll an, das der Server aus den Präferenzen des Clients ausgewählt hat.
Sec-WebSocket-Version-
In Anfragen gibt dieser Header die Version des WebSocket-Protokolls an, die der Client verwendet. In Antworten wird er nur gesendet, wenn der Server die angeforderte Protokollversion nicht unterstützt; dann listet er die unterstützten Versionen auf.
Sonstige Header
Alt-Svc-
Listet alternative Möglichkeiten auf, diesen Dienst zu erreichen.
Alt-Used-
Identifiziert den verwendeten alternativen Dienst.
Date-
Enthält Datum und Uhrzeit der Erstellung der Nachricht.
Link-
Dieses Entity-Header-Feld ermöglicht es, einen oder mehrere Links in HTTP-Headern zu serialisieren. Semantisch entspricht es dem HTML-Element
<link>. Retry-After-
Gibt an, wie lange der User-Agent warten soll, bevor er eine Folgeanfrage sendet.
Server-Timing-
Übermittelt eine oder mehrere Metriken und Beschreibungen für den jeweiligen Anfrage-Antwort-Zyklus.
Service-Worker-
Ist bei Fetch-Anfragen nach der Skriptressource eines Service Workers enthalten. Dieser Header hilft Administratoren, Anfragen nach Service-Worker-Skripten zu Überwachungszwecken zu protokollieren.
Service-Worker-Allowed-
Wird verwendet, um die Pfadbeschränkung aufzuheben, indem dieser Header in die Antwort für das Service-Worker-Skript aufgenommen wird.
SourceMap-
Verweist auf eine Source Map, damit Debugger den ursprünglichen Quellcode statt des generierten oder transformierten Codes schrittweise durchlaufen können.
Upgrade-
Mit diesem ausschließlich für HTTP/1.1 vorgesehenen Header kann eine bereits bestehende Client-Server-Verbindung auf ein anderes Protokoll umgestellt werden (bei gleichem Transportprotokoll). Ein Client kann damit beispielsweise eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- beziehungsweise HTTPS-Verbindung auf WebSocket umstellen.
Priority-
Gibt einen Hinweis auf die Priorität einer bestimmten Ressourcenanfrage innerhalb einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Priorität des Clients anzugeben, oder in einer Antwort, wenn der Server die Anfrage neu priorisieren möchte.
Experimentelle Header
>Header für Attribution Reporting
Die Attribution Reporting API ermöglicht es Entwicklern, Conversions zu messen – beispielsweise wenn ein Nutzer auf eine in einer Website eingebettete Anzeige klickt und anschließend den Artikel auf der Website des Anbieters kauft – und Berichte über diese Conversions abzurufen. Dabei verwendet sie keine Tracking-Cookies von Drittanbietern, sondern verschiedene Header, um Quellen und Auslöser zu registrieren, die zur Erkennung einer Conversion einander zugeordnet werden.
Attribution-Reporting-Eligible-
Gibt an, dass die Antwort auf die aktuelle Anfrage am Attribution Reporting teilnehmen kann, indem entweder eine Attributionsquelle oder ein Attributionsauslöser registriert wird.
Attribution-Reporting-Register-Source-
Wird als Teil einer Antwort auf eine Anfrage gesendet, die den Header
Attribution-Reporting-Eligibleenthielt, und dient zur Registrierung einer Attributionsquelle. Attribution-Reporting-Register-Trigger-
Wird als Teil einer Antwort auf eine Anfrage gesendet, die den Header
Attribution-Reporting-Eligibleenthielt, und dient zur Registrierung eines Attributionsauslösers.
Client-Hinweise
HTTP-Client-Hinweise sind Anfrage-Header, die nützliche Informationen über den Client bereitstellen, etwa zum Gerätetyp und zu den Netzwerkbedingungen. So können Server die bereitgestellten Inhalte für diese Bedingungen optimieren.
Server fordern die Client-Hinweis-Header, an denen sie interessiert sind, mithilfe von Accept-CH aktiv beim Client an. Der Client kann die angeforderten Header anschließend in weitere Anfragen aufnehmen.
Accept-CH-
Server können die Unterstützung für Client-Hinweise über das Header-Feld
Accept-CHoder ein entsprechendes HTML-Element<meta>mit dem Attributhttp-equivbekannt geben. Critical-CH-
Server verwenden
Critical-CHzusammen mitAccept-CH, um festzulegen, dass akzeptierte Client-Hinweise zugleich kritische Client-Hinweise sind.
Die verschiedenen Kategorien von Client-Hinweisen sind nachfolgend aufgeführt.
User-Agent-Client-Hinweise
Die UA-Client-Hinweise sind Anfrage-Header, die Informationen über den User-Agent, die Plattform beziehungsweise Architektur, auf der er ausgeführt wird, und über Nutzerpräferenzen bereitstellen, die im User-Agent oder auf der Plattform festgelegt wurden:
Sec-CH-UA-
Marke und Version des User-Agents.
Sec-CH-UA-Arch-
Architektur der zugrunde liegenden Plattform 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 Nutzer mit ihm interagieren.
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-
Gibt an, ob der User-Agent auf einem Mobilgerät ausgeführt wird oder allgemein eine „mobile“ Nutzererfahrung bevorzugt.
Sec-CH-UA-Model-
Gerätemodell des User-Agents.
Sec-CH-UA-Platform-
Zugrunde liegendes Betriebssystem beziehungsweise zugrunde liegende 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 der Nutzer für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion-
Präferenz der Nutzer für weniger Animationen und Verschiebungen des Inhaltslayouts.
Sec-CH-Prefers-Reduced-Transparency-
Anfrage-Header, der die Präferenz des User-Agents für reduzierte Transparenz angibt.
Hinweis: User-Agent-Client-Hinweise sind in Fenced Frames nicht verfügbar, da sie auf der Delegation von Permissions Policy beruhen, die zur Offenlegung von Daten genutzt werden könnte.
Client-Hinweise für Geräte und responsive Bilder
Sec-CH-Device-Memory-
Ungefähre Größe des verfügbaren Arbeitsspeichers des Clients. Dies ist Teil der Device Memory API.
Sec-CH-DPR-
Anfrage-Header, der das Device Pixel Ratio des Clients angibt (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 angibt.
Sec-CH-Viewport-Width-
Anfrage-Header, der die Breite des Layout-Viewports des Clients in CSS-Pixeln angibt.
Sec-CH-Width-
Anfrage-Header, der die Breite des Bildes in CSS-Pixeln angibt.
Veraltete Client-Hinweise für Geräte und responsive Bilder
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-Hinweise
Netzwerk-Client-Hinweise ermöglichen es einem Server, anhand der Entscheidung der Nutzer sowie der Bandbreite und Latenz des Netzwerks auszuwählen, welche Informationen gesendet werden.
Downlink-
Ungefähre Bandbreite der Verbindung des Clients zum Server in Mbit/s. 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-Zeit (RTT) auf Anwendungsebene in Millisekunden, einschließlich der Verarbeitungszeit des Servers. Dies ist Teil der Network Information API.
Save-Data-
Die Zeichenfolge
ongibt an, dass der User-Agent einen geringeren Datenverbrauch bevorzugt.
Compression Dictionary Transport
Compression Dictionary Transport verwendet ein gemeinsames Komprimierungswörterbuch, um die Übertragungsgröße von HTTP-Antworten zu verringern, anstatt das statische Standardwörterbuch der Brotli-Komprimierung oder Zstandard-Komprimierung zu verwenden.
Available-Dictionary-
Ein Browser kann mit diesem Anfrage-Header angeben, welches seiner verfügbaren Wörterbücher sich für die Komprimierung durch den Server am besten eignet.
Dictionary-ID-
Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource besitzt und der Server im Header
Use-As-Dictionaryeineidfür das Wörterbuch angegeben hat. Anfragen nach Ressourcen, die das Wörterbuch verwenden können, enthalten einen HeaderAvailable-Dictionarysowie die vom Server vergebene Wörterbuch-idim HeaderDictionary-ID. Use-As-Dictionary-
Listet die Übereinstimmungskriterien auf, nach denen das Wörterbuch für zukünftige Anfragen verwendet werden kann.
Datenschutz
DNT-
Anfrage-Header, der die Tracking-Präferenz der Nutzer angibt (Do Not Track). Er ist zugunsten von Global Privacy Control (GPC) veraltet. GPC wird Servern über den Header
Sec-GPCmitgeteilt und ist für Clients übernavigator.globalPrivacyControlzugänglich. Tk-
Antwort-Header, der den Tracking-Status angibt, der für die zugehörige Anfrage galt. Wird zusammen mit DNT verwendet.
Sec-GPC-
Gibt an, ob die Nutzer damit einverstanden sind, dass eine Website oder ein Dienst ihre personenbezogenen Daten an Dritte verkauft oder weitergibt.
Sicherheit
Origin-Agent-Cluster-
Antwort-Header, der angibt, dass das zugehörige
Documenteinem nach Origin getrennten Agent-Cluster zugewiesen werden soll. Diese Isolierung ermöglicht es User-Agents, implementierungsspezifische Ressourcen wie Prozesse oder Threads effizienter Agent-Clustern zuzuweisen.
Server-Sent Events
NEL-
Definiert einen Mechanismus, mit dem Entwickler eine Richtlinie zur Meldung von Netzwerkfehlern festlegen können.
Topics API
Die Topics API bietet Entwicklern einen Mechanismus, um Anwendungsfälle wie interessenbasierte Werbung (IBA) umzusetzen. Weitere Informationen finden Sie in der Dokumentation zur Topics API.
Observe-Browsing-Topics-
Antwort-Header, mit dem aus der URL einer aufrufenden Website abgeleitete Interessenthemen als beobachtet markiert werden. Er wird als Antwort auf eine Anfrage verwendet, die durch eine Funktion mit Unterstützung für die Topics API erzeugt wurde.
Sec-Browsing-Topics-
Anfrage-Header, der die ausgewählten Themen für den aktuellen Nutzer zusammen mit der zugehörigen Anfrage sendet. Eine Werbetechnologieplattform verwendet sie, um eine personalisierte Anzeige auszuwählen.
Sonstige Header
Early-Data-
Gibt an, dass die Anfrage über TLS Early Data übertragen wurde.
Idempotency-Key-
Stellt einen eindeutigen Schlüssel für
POST- undPATCH-Anfragen bereit, damit diese idempotent ausgeführt werden können. Set-Login-
Antwort-Header, den ein föderierter Identitätsanbieter (IdP) sendet, um seinen Anmeldestatus festzulegen – also ob im aktuellen Browser Nutzer beim IdP angemeldet sind. Der Browser speichert diesen Status und verwendet ihn für die FedCM API.
Speculation-Rules-
Stellt eine Liste von URLs bereit, die auf Textressourcen mit JSON-Definitionen von Speculation Rules verweisen. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln dem Regelsatz des Dokuments hinzugefügt.
-
Enthält einen oder mehrere Tag-Werte aus den Speculation Rules, die zur spekulativen Aktion geführt haben. So kann ein Server erkennen, welche Regeln sie ausgelöst haben, und diese gegebenenfalls blockieren.
Supports-Loading-Mode-
Wird von einem Navigationsziel gesetzt, um die Verwendung verschiedener risikoreicherer Lademodi zuzulassen. Beispielsweise erfordert Prerendering für einen anderen Origin innerhalb derselben Site den Wert
credentialed-prerenderfürSupports-Loading-Mode.
Nicht standardisierte Header
X-Forwarded-For-
Identifiziert die ursprünglichen IP-Adressen eines Clients, der sich über einen HTTP-Proxy oder Load Balancer mit einem Webserver verbindet.
X-Forwarded-Host-
Identifiziert den ursprünglich angeforderten Host, über den sich ein Client mit Ihrem Proxy oder Load Balancer verbunden hat.
X-Forwarded-Proto-
Identifiziert das Protokoll (HTTP oder HTTPS), mit dem sich ein Client mit Ihrem Proxy oder Load Balancer verbunden hat.
X-DNS-Prefetch-Control-
Steuert DNS-Prefetching. Dabei lösen Browser Domainnamen vorsorglich auf – sowohl für Links, denen Nutzer möglicherweise folgen, als auch für URLs von Ressourcen, auf die das Dokument verweist, darunter Bilder, CSS und JavaScript.
X-Robots-Tag-
Der HTTP-Header
X-Robots-Taggibt an, wie eine Webseite in den Ergebnissen öffentlicher Suchmaschinen indexiert werden soll. Er entspricht den Elementen<meta name="robots">.
Veraltete Header
Pragma-
Implementierungsspezifischer Header, der an jeder Stelle der Anfrage-Antwort-Kette unterschiedliche Auswirkungen haben kann. Er dient der Abwärtskompatibilität mit HTTP/1.0-Caches, in denen der Header
Cache-Controlnoch nicht vorhanden ist. Warning-
Allgemeine Warninformationen über mögliche Probleme.