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 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 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, 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.

Proxy-Authorization

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.

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 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 identifiziert. 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 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 TRACE die 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-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 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-Encoding und Content-Range abhängt.

Repr-Digest

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

Want-Content-Digest

Drückt den Wunsch nach einem Content-Digest-Header aus. Er ist das Content--Gegenstück zu Want-Repr-Digest.

Want-Repr-Digest

Drückt den Wunsch nach einem Repr-Digest-Header aus. Er ist das Repr--Gegenstück zu Want-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-Signature fordert eine signierte Antwort oder eine nachfolgende signierte Anfrage an und gibt die zu signierenden Komponenten sowie die Signaturparameter an.

Signature

Der Header Signature enthält einen oder mehrere mit Labels versehene Signaturwerte. Jedes Label 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 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 Prefer angegebenen Präferenzen der Server angewendet hat. Dieser ausschließlich in Antworten verwendete Header macht die Behandlung von Präferenzen nachvollziehbar.

Proxys

Forwarded

Enthält Informationen von der dem Client zugewandten Seite von Proxyservern, die verloren gehen oder verändert werden, wenn ein Proxy am Anfrageweg beteiligt ist.

Via

Wird von Forward- und Reverse-Proxys hinzugefügt und kann sowohl in Anfrage- als auch in Antwort-Headern vorkommen.

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 mit http-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 Referer bei 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

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, 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-Policy oder 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-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 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-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 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-site und none ist.

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

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

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: prefetch zeigt an, dass die Ressource vorsorglich für eine mögliche spätere Navigation abgerufen wird.

Service-Worker-Navigation-Preload

Ein Anfrage-Header, der bei einer vorsorglichen Anfrage gesendet wird, um während des Starts eines Service Workers eine Ressource mit fetch() abzurufen. Sein mit NavigationPreloadManager.setHeaderValue() festgelegter Wert kann dem Server mitteilen, dass er eine andere Ressource als bei einer gewöhnlichen fetch()-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, 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. Ist der Status active, 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-Access verwendet, 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.

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-Eligible enthielt, und dient zur Registrierung einer Attributionsquelle.

Attribution-Reporting-Register-Trigger

Wird als Teil einer Antwort auf eine Anfrage gesendet, die den Header Attribution-Reporting-Eligible enthielt, 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-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 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.

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 on gibt 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-Dictionary eine id für das Wörterbuch angegeben hat. Anfragen nach Ressourcen, die das Wörterbuch verwenden können, enthalten einen Header Available-Dictionary sowie die vom Server vergebene Wörterbuch-id im Header Dictionary-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-GPC mitgeteilt und ist für Clients über navigator.globalPrivacyControl zugä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 Document einem 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- und PATCH-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.

Sec-Speculation-Tags

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

Warning

Allgemeine Warninformationen über mögliche Probleme.

Siehe auch