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 Groß- und Kleinschreibung keine Rolle spielt, gefolgt von einem Doppelpunkt, optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel Allow: POST).
In HTTP/2 und neueren Versionen werden Header in Entwicklertools kleingeschrieben angezeigt (accept: */*). Eine besondere Gruppe von Pseudo-Headern beginnt außerdem mit einem Doppelpunkt (: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 aufgrund der Schwierigkeiten aufgegeben, die entstanden, wenn nicht standardisierte Felder standardisiert wurden. Weitere Header sind im IANA-Register für HTTP-Feldnamen aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde.
Das IANA-Register führt Header einschließlich Informationen zu ihrem Status auf.
Header lassen sich nach ihrem Kontext gruppieren:
- Request-Header
-
Enthalten weitere Informationen über die abzurufende Ressource oder den Client, der sie anfordert.
- Response-Header
-
Enthalten zusätzliche Informationen über die Antwort, etwa ihren Speicherort oder den Server, der sie bereitstellt.
- Repräsentations-Header
-
Enthalten Informationen über den Body der Ressource, etwa ihren MIME-Typ oder die verwendete Kodierung beziehungsweise Komprimierung.
- Payload-Header
-
Enthalten repräsentationsunabhä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 mit ihnen umgehen:
- 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. Zwischengeschaltete 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 zur Authentifizierung eines User-Agents bei einem Server.
Proxy-Authenticate-
Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource hinter einem Proxyserver verwendet werden soll.
-
Enthält die Anmeldedaten zur Authentifizierung eines User-Agents bei einem Proxyserver.
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-
Das Datum und die Uhrzeit, ab denen die Antwort als veraltet gilt.
No-Vary-Search-
Legt Regeln fest, die bestimmen, wie sich die Abfrageparameter einer URL auf den Abgleich mit dem Cache auswirken. Diese Regeln bestimmen, ob dieselbe URL mit unterschiedlichen URL-Parametern als getrennte Einträge im Browser-Cache gespeichert werden soll.
Bedingte Anfragen
Last-Modified-
Das Datum der letzten Änderung der Ressource. Es wird verwendet, um mehrere 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 kennzeichnet. 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 zu verhindern, dass eine neue Ressource hochgeladen wird, wenn bereits eine vorhanden ist.
If-Modified-Since-
Macht die Anfrage bedingt und fordert die Übertragung der Ressource nur an, 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 fordert die Übertragung der Ressource nur an, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dadurch wird sichergestellt, dass ein neues Fragment eines bestimmten Bereichs mit früheren Fragmenten konsistent ist. Der Header kann auch verwendet werden, um beim Ändern vorhandener Dokumente eine optimistische Nebenläufigkeitskontrolle zu implementieren.
Vary-
Legt fest, wie Request-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, statt eine neue Antwort 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-
Informiert den Server darüber, welche Datentypen er zurücksenden kann.
Accept-Encoding-
Der Kodierungsalgorithmus, in der Regel ein Komprimierungsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.
Accept-Language-
Informiert den Server darüber, in welcher natürlichen Sprache er die Antwort voraussichtlich zurücksenden soll. Dies ist ein Hinweis und unterliegt nicht unbedingt vollständig der Kontrolle des Benutzers: Der Server sollte darauf achten, eine ausdrückliche Entscheidung des Benutzers (etwa die Auswahl einer Sprache aus einer Dropdown-Liste) nicht zu übergehen.
Accept-Patch-
Ein Response-Header zur Inhaltsaushandlung für Anfragen, der angibt, welche Medientypen der Server in einer
PATCH-Anfrage verarbeiten kann. Accept-Post-
Ein Response-Header zur Inhaltsaushandlung für Anfragen, der angibt, welche Medientypen der Server in einer
POST-Anfrage verarbeiten kann. Accept-Query-
Ein Response-Header zur Inhaltsaushandlung für Anfragen, 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 von Hops an, die die Anfrage durchlaufen darf, bevor sie an den Absender zurückgesendet 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 auf „true“ gesetzt 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 geteilt werden darf.
Access-Control-Expose-Headers-
Gibt anhand einer Liste ihrer Namen an, welche Header 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 Ursprung eine Fetch-Anfrage ausgeht.
Timing-Allow-Origin-
Gibt Ursprünge an, die Werte von Attributen einsehen dürfen, die über Funktionen der Resource Timing API abgerufen werden. 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 Dialog zum Speichern anzeigen soll.
Integritäts-Digests
Content-Digest-
Stellt einen Digest des Oktettstroms bereit, der in einer HTTP-Nachricht enthalten ist (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 dieser Digest wederContent-EncodingnochContent-Range. Want-Content-Digest-
Gibt an, dass ein
Content-Digest-Header gewünscht wird. Es ist dasContent--Gegenstück zuWant-Repr-Digest. Want-Repr-Digest-
Gibt an, dass ein
Repr-Digest-Header gewünscht wird. Es ist dasRepr--Gegenstück zuWant-Content-Digest.
Integritätsrichtlinie
Integrity-Policy-
Stellt sicher, dass alle vom User-Agent geladenen Ressourcen eines bestimmten Typs Garantien für die Subresource Integrity erfüllen.
Integrity-Policy-Report-Only-
Meldet vom User-Agent geladene Ressourcen, die gegen die Garantien für die Subresource Integrity verstoßen würden, wenn die Integritätsrichtlinie (mithilfe des Headers
Integrity-Policy) durchgesetzt würde.
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-
Gibt den verwendeten Komprimierungsalgorithmus an.
Content-Language-
Beschreibt die natürliche Sprache oder die natürlichen Sprachen, die für die Zielgruppe vorgesehen sind, damit Benutzer Inhalte entsprechend 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 Signaturparameter an. Signature-
Der Header
Signatureenthält einen oder mehrere mit Bezeichnungen versehene Signaturwerte. Jede Bezeichnung 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 Erstellungszeitpunkt und Schlüsselkennung.
Hinweis:
Diese Definitionen folgen RFC 9421. Der Entwurf zu Signed HTTP Exchanges (SXG) definiert ebenfalls Accept-Signature und Signature, 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 andernfalls nicht eindeutig wäre. Browser unterstützen das Senden von Präferenzen über diese Header nicht nativ. Sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.
Prefer-
Gibt Präferenzen für bestimmte Verhaltensweisen des Servers bei der Verarbeitung einer Anfrage an. Beispielsweise kann damit ein minimaler Antwortinhalt (
return=minimal) oder eine asynchrone Verarbeitung (respond-async) angefordert werden. Wird der Header nicht unterstützt, verarbeitet der Server die Anfrage wie gewohnt. Preference-Applied-
Informiert den Client darüber, welche im Header
Preferangegebenen Präferenzen der Server angewendet hat. Dieser reine Response-Header macht den Umgang mit Präferenzen nachvollziehbar.
Proxys
Forwarded-
Enthält Informationen von der dem Client zugewandten Seite von Proxyservern, die verändert werden oder verloren gehen, wenn ein Proxy am Anfragepfad beteiligt ist.
Via-
Wird von Proxys – sowohl Forward- als auch Reverse-Proxys – hinzugefügt und kann in Request- und Response-Headern vorkommen.
Bereichsanfragen
Mit HTTP-Bereichsanfragen kann ein Client einen Teil einer Ressource vom Server anfordern. Bereichsanfragen sind beispielsweise für Mediaplayer nützlich, die wahlfreien Zugriff unterstützen, für Datenwerkzeuge, die nur einen Teil einer großen Datei benötigen, und für Download-Manager, mit denen Benutzer Downloads pausieren 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-
Erstellt 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 der Ressource heruntergeladen werden.
Content-Range-
Gibt an, an welcher Stelle des vollständigen Nachrichten-Bodys 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 Element
metamithttp-equiv="refresh".
Anfragekontext
From-
Enthält die Internet-E-Mail-Adresse eines 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 auf Verbindungen wartet.
Referer-
Die Adresse der vorherigen Webseite, auf der sich ein Link zur aktuell angeforderten Seite befand.
Referrer-Policy-
Regelt, welche Referrer-Informationen, die im Header
Referergesendet werden, in Anfragen enthalten sein sollen. User-Agent-
Enthält eine charakteristische Zeichenfolge, anhand derer die Kommunikationspartner im Netzwerkprotokoll den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfragenden User-Agents erkennen können.
Antwortkontext
Sicherheit
Cross-Origin-Embedder-Policy(COEP)-
Ermöglicht es einem Server, für ein bestimmtes Dokument eine Einbettungsrichtlinie 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. Weitere Informationen finden Sie im 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, Richtlinien zu erproben, indem sie deren Auswirkungen überwachen, ohne sie durchzusetzen. Die Berichte über Richtlinienverstöße bestehen aus JSON-Dokumenten, die über eine HTTP-
POST-Anfrage an den angegebenen URI gesendet werden. Expect-CT-
Ermöglicht Websites, die Meldung und Durchsetzung von Certificate Transparency zu aktivieren, um die Verwendung fehlerhaft ausgestellter Zertifikate für die jeweilige Website zu erkennen.
Permissions-Policy-
Bietet einen Mechanismus, um die Verwendung von Browserfunktionen im eigenen Frame einer Website und in den von ihr eingebetteten
<iframe>s zu erlauben oder zu verbieten. Reporting-Endpoints-
Ein Response-Header, mit dem Websitebetreiber einen oder mehrere Endpunkte für den Empfang von Fehlermeldungen festlegen können, etwa Berichte über CSP-Verstöße,
Cross-Origin-Opener-Policy-Berichte oder andere allgemeine Verstöße. Strict-Transport-Security(HSTS)-
Erzwingt die Kommunikation über HTTPS statt über 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 die Verarbeitung von Daten über Domaingrenzen hinweg erlauben, die andernfalls aufgrund der Same-Origin Policy 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 über sie, 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-Metadata-Request-Header
Fetch-Metadata-Request-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 die Anfrage zugelassen werden soll.
Sec-Fetch-Site-
Gibt die Beziehung zwischen dem Ursprung des Anfragenauslösers und dem Ursprung des Ziels an. Es handelt sich um einen Structured Header, dessen Wert ein Token mit einem der möglichen Werte
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 einem der möglichen Werte
cors,navigate,no-cors,same-originundwebsocketist. Sec-Fetch-User-
Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktion ausgelöst wurde. Es handelt sich um einen Structured Header mit einem booleschen Wert:
?0für „false“ und?1für „true“. Sec-Fetch-Dest-
Gibt das Ziel der Anfrage an. Es handelt sich um einen Structured Header, dessen Wert ein Token mit einem der möglichen Werte
audio,audioworklet,document,embed,empty,font,image,manifest,object,paintworklet,report,script,serviceworker,sharedworker,style,track,video,workerundxsltist.
Die folgenden Request-Header sind streng genommen keine Fetch-Metadata-Request-Header, liefern aber ebenfalls Informationen über den Kontext, in dem eine Ressource verwendet werden soll. 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:
prefetch. Dieser zeigt an, dass die Ressource vorsorglich für eine mögliche spätere Navigation abgerufen wird. -
Ein Request-Header, der bei einer vorgezogenen Anfrage zum Abrufen einer Ressource mit
fetch()während des Starts eines Service Workers gesendet wird. Der mitNavigationPreloadManager.setHeaderValue()festgelegte Wert kann dem Server mitteilen, dass er eine andere Ressource als bei einem normalenfetch()-Aufruf zurückgeben soll.
Header für den Fetch-Speicherzugriff
Diese Header ermöglichen einen erweiterten Ablauf für die Storage Access API.
Sec-Fetch-Storage-Access-
Gibt den „Speicherzugriffsstatus“ für den aktuellen Fetch-Kontext an. Dieser hat einen der Werte
none,inactiveoderactive. Der Server kann mitActivate-Storage-Accessantworten, um den Browser aufzufordern, eineinactive-Berechtigung zu aktivieren und die Anfrage zu wiederholen. Wenn der Statusactiveist, kann er außerdem anfordern, eine Ressource mit Zugriff auf deren Drittanbieter-Cookies zu laden. Activate-Storage-Access-
Wird als Antwort auf
Sec-Fetch-Storage-Accessverwendet, um anzuzeigen, dass der Browser eine vorhandene Berechtigung für sicheren Zugriff aktivieren und die Anfrage mit Cookies wiederholen kann. Ist die Berechtigung bereits aktiviert, kann er eine Ressource mit Cookie-Zugriff laden.
Server-Sent Events
Reporting-Endpoints-
Ein Response-Header, der Server-Endpunkte angibt, an die der Browser bei Verwendung der Reporting API Warn- und Fehlerberichte senden soll.
Report-To-
Ein Response-Header, der Server-Endpunkte angibt, 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 Benutzer übertragen wird.
TE-
Gibt an, welche Übertragungskodierungen der User-Agent akzeptiert.
Trailer-
Ermöglicht es dem Absender, zusätzliche Felder am Ende einer in Chunks übertragenen Nachricht einzufügen.
WebSockets
Header, die von der WebSockets API beim WebSocket-Handshake verwendet werden:
Sec-WebSocket-Accept-
Ein Response-Header, der angibt, dass der Server bereit ist, die Verbindung auf eine WebSocket-Verbindung umzustellen.
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-
Ein Request-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 vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn der Server die angeforderte Protokollversion nicht unterstützt, und listet die vom Server unterstützten Versionen auf.
Sonstige
Alt-Svc-
Listet alternative Möglichkeiten auf, diesen Dienst zu erreichen.
Alt-Used-
Kennzeichnet den verwendeten alternativen Dienst.
Date-
Enthält Datum und Uhrzeit, zu denen die Nachricht erstellt wurde.
Link-
Dieses Entity-Header-Feld ermöglicht es, einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch gleichwertig mit dem 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 jeweiligen Anfrage-Antwort-Zyklus.
Service-Worker-
Ist in Fetch-Anfragen für die 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 auf das Service-Worker-Skript aufgenommen wird.
SourceMap-
Verweist auf eine Source Map, damit Debugger statt durch generierten oder transformierten Code durch den ursprünglichen Quellcode schrittweise navigieren 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 (über dasselbe Transportprotokoll). Beispielsweise kann ein Client damit 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 über eine bestimmte 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
Mit der Attribution Reporting API können Entwickler Conversions messen – beispielsweise, wenn ein Benutzer auf eine in einer Website eingebettete Anzeige klickt und anschließend den beworbenen Artikel auf der Website des Anbieters kauft – und Berichte über diese Conversions abrufen. Statt sich auf Tracking-Cookies von Drittanbietern zu stützen, verwendet sie verschiedene Header, um Quellen und Auslöser zu registrieren, die zur Feststellung einer Conversion miteinander abgeglichen 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 der Antwort auf eine Anfrage mit dem Header
Attribution-Reporting-Eligiblegesendet und zur Registrierung einer Attributionsquelle verwendet. Attribution-Reporting-Register-Trigger-
Wird als Teil der Antwort auf eine Anfrage mit dem Header
Attribution-Reporting-Eligiblegesendet und zur Registrierung eines Attributionsauslösers verwendet.
Client Hints
HTTP-Client Hints sind Request-Header, die nützliche Informationen über den Client bereitstellen, etwa den Gerätetyp und die Netzwerkbedingungen. Server können damit die bereitgestellten Inhalte an diese Bedingungen anpassen.
Server fordern die Client-Hint-Header, an denen sie interessiert sind, über Accept-CH beim Client an. Der Client kann daraufhin entscheiden, die angeforderten Header in nachfolgende Anfragen aufzunehmen.
Accept-CH-
Server können ihre Unterstützung für Client Hints ü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 anzugeben, dass akzeptierte Client Hints zugleich kritische Client Hints sind.
Die verschiedenen Kategorien von Client Hints sind nachfolgend aufgeführt.
User-Agent-Client-Hints
UA-Client-Hints sind Request-Header, die Informationen über den User-Agent, die zugrunde liegende Plattform und Architektur sowie über die im User-Agent oder auf der Plattform festgelegten Benutzerpräferenzen bereitstellen:
Sec-CH-UA-
Marke und Version des User-Agents.
Sec-CH-UA-Arch-
Architektur der dem User-Agent zugrunde liegenden Plattform.
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 Benutzer 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-
Der User-Agent läuft auf einem mobilen Gerät oder bevorzugt allgemein eine „mobile“ Benutzererfahrung.
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 einem 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 für weniger Animationen und Layoutverschiebungen.
Sec-CH-Prefers-Reduced-Transparency-
Ein Request-Header, der die Präferenz des User-Agents für reduzierte Transparenz angibt.
Hinweis: User-Agent-Client-Hints sind innerhalb von Fenced Frames nicht verfügbar, da sie auf der Delegierung über eine Permissions Policy beruhen, die zur Offenlegung von Daten genutzt werden könnte.
Client Hints 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-
Ein Request-Header, der das Gerätepixelverhältnis des Clients angibt (die Anzahl physischer Gerätepixel pro CSS-Pixel).
Sec-CH-Viewport-Height-
Ein Request-Header, der die Höhe des Layout-Viewports des Clients in CSS-Pixeln angibt.
Sec-CH-Viewport-Width-
Ein Request-Header, der die Breite des Layout-Viewports des Clients in CSS-Pixeln angibt.
Sec-CH-Width-
Ein Request-Header, der die Breite des Bildes in CSS-Pixeln angibt.
Veraltete Client Hints 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-Hints
Netzwerk-Client-Hints ermöglichen es einem Server, die gesendeten Informationen anhand der Benutzerentscheidung sowie der Bandbreite und Latenz der Netzwerkverbindung auszuwählen.
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-
Umlaufzeit (RTT) auf Anwendungsebene in Millisekunden, einschließlich der Verarbeitungszeit des Servers. Dies ist Teil der Network Information API.
Save-Data-
Die Zeichenfolge
on, die die Präferenz des User-Agents für einen geringeren Datenverbrauch angibt.
Compression Dictionary Transport
Compression Dictionary Transport verwendet ein gemeinsames Komprimierungswörterbuch, um die Übertragungsgröße von HTTP-Antworten zu verringern, statt das statische Standardwörterbuch der Brotli-Komprimierung oder Zstandard-Komprimierung zu verwenden.
Available-Dictionary-
Ein Browser kann mit diesem Request-Header das beste verfügbare Wörterbuch angeben, das der Server zur Komprimierung verwenden kann.
Dictionary-ID-
Wird verwendet, wenn dem Browser bereits ein Wörterbuch für eine Ressource zur Verfügung steht und der Server im Header
Use-As-Dictionaryeineidfür das Wörterbuch angegeben hat. Anfragen nach Ressourcen, für die das Wörterbuch verwendet werden kann, enthalten einen HeaderAvailable-Dictionarysowie die vom Server bereitgestellte Wörterbuch-idim HeaderDictionary-ID. Use-As-Dictionary-
Listet die Abgleichkriterien auf, unter denen das Wörterbuch bei zukünftigen Anfragen verwendet werden kann.
Datenschutz
DNT-
Ein Request-Header, der die Tracking-Präferenz des Benutzers 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-
Ein Response-Header, der den für die zugehörige Anfrage geltenden Tracking-Status angibt. Wird zusammen mit DNT verwendet.
Sec-GPC-
Gibt an, ob der Benutzer dem Verkauf oder der Weitergabe seiner personenbezogenen Daten durch eine Website oder einen Dienst an Dritte zustimmt.
Sicherheit
Origin-Agent-Cluster-
Ein Response-Header, der angibt, dass das zugehörige
Documentin einem nach Ursprung abgegrenzten Agent-Cluster platziert werden soll. Diese Isolation ermöglicht es User-Agents, implementierungsspezifische Ressourcen wie Prozesse oder Threads effizienter für Agent-Cluster zuzuweisen.
Server-Sent Events
NEL-
Definiert einen Mechanismus, mit dem Entwickler eine Richtlinie für die Meldung von Netzwerkfehlern festlegen können.
Topics API
Die Topics API bietet Entwicklern einen Mechanismus zur Umsetzung von Anwendungsfällen wie interessenbezogener Werbung (IBA). Weitere Informationen finden Sie in der Dokumentation zur Topics API.
Observe-Browsing-Topics-
Ein Response-Header, mit dem aus der URL einer aufrufenden Website abgeleitete Interessenthemen in der Antwort auf eine Anfrage als beobachtet markiert werden. Die Anfrage wurde durch eine Funktion erzeugt, die die Topics API aktiviert.
Sec-Browsing-Topics-
Ein Request-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet. Eine Werbetechnologieplattform nutzt diese Themen, um eine personalisierte Anzeige auszuwählen.
Sonstige
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-
Ein Response-Header, den ein föderierter Identitätsanbieter (IdP) sendet, um seinen Anmeldestatus festzulegen: ob im aktuellen Browser Benutzer beim IdP angemeldet sind oder nicht. 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 Spekulation geführt haben. So kann ein Server erkennen, welche Regeln die Spekulation ausgelöst haben, und sie gegebenenfalls blockieren.
Supports-Loading-Mode-
Wird von einem Navigationsziel gesetzt, um die Verwendung verschiedener risikoreicherer Lademodi zu erlauben. Beispielsweise erfordert Prerendering zwischen verschiedenen Ursprüngen innerhalb derselben Site den Wert
credentialed-prerenderfürSupports-Loading-Mode.
Nicht standardisierte Header
X-Forwarded-For-
Kennzeichnet die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder Load Balancer eine Verbindung zu einem Webserver herstellt.
X-Forwarded-Host-
Kennzeichnet den ursprünglich angeforderten Host, über den ein Client eine Verbindung zu Ihrem Proxy oder Load Balancer hergestellt hat.
X-Forwarded-Proto-
Kennzeichnet das Protokoll (HTTP oder HTTPS), mit dem ein Client eine Verbindung zu Ihrem Proxy oder Load Balancer hergestellt hat.
X-DNS-Prefetch-Control-
Steuert das DNS-Prefetching. Bei dieser Funktion lösen Browser Domainnamen vorsorglich auf – sowohl für Links, denen Benutzer 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 öffentlichen Suchmaschinenergebnissen indexiert werden soll. Der Header entspricht<meta name="robots">-Elementen.
Veraltete Header
Pragma-
Ein implementierungsspezifischer Header, der an beliebiger Stelle in 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 zu möglichen Problemen.