Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.

View in English Always switch to English

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 Connection nur 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.

Authorization

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.

Proxy-Authorization

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.

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 mit If-Modified-Since und If-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.

ETag

Eine eindeutige Zeichenfolge, die die Version der Ressource kennzeichnet. Bedingte Anfragen mit If-Match und If-None-Match verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.

If-Match

Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.

If-None-Match

Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource 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 TRACE die 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-Cookie gesendet 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-Encoding und Content-Range.

Repr-Digest

Stellt einen Digest der ausgewählten Repräsentation der Zielressource vor der Übertragung bereit. Anders als Content-Digest berücksichtigt dieser Digest weder Content-Encoding noch Content-Range.

Want-Content-Digest

Gibt an, dass ein Content-Digest-Header gewünscht wird. Es ist das Content--Gegenstück zu Want-Repr-Digest.

Want-Repr-Digest

Gibt an, dass ein Repr-Digest-Header gewünscht wird. Es ist das Repr--Gegenstück zu Want-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-Signature fordert eine signierte Antwort oder eine nachfolgende signierte Anfrage an und gibt die zu signierenden Komponenten sowie Signaturparameter an.

Signature

Der Header Signature enthält einen oder mehrere mit Bezeichnungen versehene Signaturwerte. Jede Bezeichnung entspricht einem Eintrag in Signature-Input.

Signature-Input

Der Header Signature-Input gibt 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 Prefer angegebenen 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 meta mit http-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 Referer gesendet 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

Allow

Listet die HTTP-Anfragemethoden auf, die eine Ressource unterstützt.

Server

Enthält Informationen über die Software, mit der der Ursprungsserver die Anfrage verarbeitet.

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-requests erfolgreich verarbeiten kann.

X-Content-Type-Options

Deaktiviert MIME-Sniffing und zwingt den Browser, den in Content-Type angegebenen 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-Policies setzt 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-site und none ist.

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-origin und websocket ist.

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: ?0 für „false“ und ?1 fü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, worker und xslt ist.

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.

Service-Worker-Navigation-Preload

Ein Request-Header, der bei einer vorgezogenen Anfrage zum Abrufen einer Ressource mit fetch() während des Starts eines Service Workers gesendet wird. Der mit NavigationPreloadManager.setHeaderValue() festgelegte Wert kann dem Server mitteilen, dass er eine andere Ressource als bei einem normalen fetch()-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, inactive oder active. Der Server kann mit Activate-Storage-Access antworten, um den Browser aufzufordern, eine inactive-Berechtigung zu aktivieren und die Anfrage zu wiederholen. Wenn der Status active ist, 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-Access verwendet, 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.

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-Eligible gesendet und zur Registrierung einer Attributionsquelle verwendet.

Attribution-Reporting-Register-Trigger

Wird als Teil der Antwort auf eine Anfrage mit dem Header Attribution-Reporting-Eligible gesendet 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-CH oder ein entsprechendes HTML-Element <meta> mit dem Attribut http-equiv bekannt geben.

Critical-CH

Server verwenden Critical-CH zusammen mit Accept-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.

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-Dictionary eine id für das Wörterbuch angegeben hat. Anfragen nach Ressourcen, für die das Wörterbuch verwendet werden kann, enthalten einen Header Available-Dictionary sowie die vom Server bereitgestellte Wörterbuch-id im Header Dictionary-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-GPC mitgeteilt und ist für Clients über navigator.globalPrivacyControl zugä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 Document in 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- und PATCH-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.

Sec-Speculation-Tags

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-prerender für Supports-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-Tag gibt 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-Control noch nicht vorhanden ist.

Warning

Allgemeine Warninformationen zu möglichen Problemen.

Siehe auch