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 dem Client und dem Server, mit einer Nachricht in einer Anfrage oder Antwort zusätzliche Informationen zu übermitteln. In HTTP/1.X ist ein Header ein Name ohne Beachtung der Groß- und Kleinschreibung, gefolgt von einem Doppelpunkt, anschließend optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header bei der Anzeige in Entwicklerwerkzeugen kleingeschrieben dargestellt (accept: */*) und für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt vorangestellt (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden historisch mit dem Präfix X- verwendet, aber diese Konvention wurde 2012 aufgrund der Unannehmlichkeiten, die sie verursachte, wenn nicht standardisierte Felder in RFC 6648 standardisiert wurden, als veraltet eingestuft; weitere sind in der IANA HTTP Field Name Registry aufgeführt, deren ursprünglicher Inhalt in RFC 4229 definiert wurde. Die IANA-Registry führt Header auf, einschließlich Informationen zu ihrem Status.

Header können anhand ihres Kontexts gruppiert werden:

Anfrage-Header

Enthalten weitere Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.

Antwort-Header

Enthalten zusätzliche Informationen über die Antwort, etwa ihren Ort oder den Server, der sie bereitstellt.

Repräsentations-Header

Enthalten Informationen über den Body der Ressource, etwa ihren MIME-Typ oder die angewendete Kodierung/Komprimierung.

Payload-Header

Enthalten repräsentationsunabhängige Informationen über Payload-Daten, einschließlich der Inhaltslänge und der für den Transport verwendeten Kodierung.

Header können auch danach gruppiert werden, wie Proxys sie behandeln:

End-to-End-Header

Diese Header müssen an den endgültigen Empfänger der Nachricht übertragen werden: den Server bei einer Anfrage oder den Client bei einer Antwort. Zwischenliegende Proxys müssen diese Header unverändert weiterleiten und Caches müssen sie speichern.

Hop-by-Hop-Header

Diese Header sind nur für eine einzelne Verbindung auf Transportebene relevant und dürfen nicht von Proxys weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mithilfe des Headers Connection gesetzt werden können.

Authentifizierung

WWW-Authenticate

Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource verwendet werden soll.

Authorization

Enthält die Zugangsdaten zur Authentifizierung eines User-Agents gegenüber einem Server.

Proxy-Authenticate

Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource hinter einem Proxyserver verwendet werden soll.

Proxy-Authorization

Enthält die Zugangsdaten zur Authentifizierung eines User-Agents gegenüber einem Proxyserver.

Caching

Age

Die Zeit in Sekunden, die sich das Objekt in einem Proxy-Cache befunden hat.

Cache-Control

Direktiven für Caching-Mechanismen sowohl in Anfragen als auch in Antworten.

Clear-Site-Data

Löscht Browsing-Daten (z. B. Cookies, Speicher, Cache), die mit der anfragenden Website verknüpft sind.

Expires

Das Datum bzw. die Uhrzeit, nach dem bzw. der die Antwort als veraltet gilt.

Gibt eine Reihe von Regeln an, die definieren, wie die Abfrageparameter einer URL den Cache-Abgleich beeinflussen. Diese Regeln legen fest, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Bedingungen

Last-Modified

Das Datum der letzten Änderung der Ressource, das zum Vergleich mehrerer Versionen derselben Ressource verwendet wird. Es ist weniger genau als ETag, in einigen Umgebungen jedoch einfacher zu berechnen. Bedingte Anfragen, die If-Modified-Since und If-Unmodified-Since verwenden, nutzen diesen Wert, um das Verhalten der Anfrage zu ändern.

ETag

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

If-Match

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

If-None-Match

Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit keinem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (bei sicheren Anfragen) oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine existiert.

If-Modified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur zu übertragen, wenn der Cache nicht mehr aktuell ist.

If-Unmodified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies stellt die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen Fragmenten sicher oder implementiert beim Ändern vorhandener Dokumente ein System zur optimistischen Nebenläufigkeitssteuerung.

Vary

Legt fest, wie Anfrage-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Origin-Server anzufordern.

Verbindungsverwaltung

Connection

Steuert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion geöffnet bleibt.

Keep-Alive

Steuert, wie lange eine persistente Verbindung geöffnet bleiben soll.

Inhaltsaushandlung

Weitere Einzelheiten finden Sie im Artikel zur Inhaltsaushandlung.

Accept

Informiert den Server über die Typen von Daten, die zurückgesendet werden können.

Accept-Encoding

Der Kodierungsalgorithmus, üblicherweise ein Komprimierungsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.

Accept-Language

Informiert den Server über die natürliche Sprache, die der Server voraussichtlich zurücksenden soll. Dies ist ein Hinweis und liegt nicht unbedingt vollständig unter der Kontrolle des Benutzers: Der Server sollte stets darauf achten, eine ausdrückliche Auswahl des Benutzers nicht zu überschreiben, beispielsweise die Auswahl einer Sprache aus einer Dropdown-Liste.

Accept-Patch

Ein Antwort-Header für Anfrage-Inhaltsaushandlung, der ankündigt, welchen Medientyp der Server in einer PATCH-Anfrage verstehen kann.

Accept-Post

Ein Antwort-Header für Anfrage-Inhaltsaushandlung, der ankündigt, welchen Medientyp der Server in einer POST-Anfrage verstehen kann.

Steuerung

Expect

Gibt Erwartungen an, die vom Server erfüllt werden müssen, damit die Anfrage ordnungsgemäß verarbeitet werden kann.

Max-Forwards

Gibt bei Verwendung von TRACE die maximale Anzahl von Hops an, die die Anfrage durchlaufen darf, bevor sie an den Absender zurückgespiegelt wird.

Cookies

Enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem Header Set-Cookie gesendet wurden.

Sendet Cookies vom Server an den User-Agent.

CORS

Weitere Informationen finden Sie in der CORS-Dokumentation.

Access-Control-Allow-Credentials

Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Credentials-Flag wahr ist.

Access-Control-Allow-Headers

Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden können.

Access-Control-Allow-Methods

Gibt die beim Zugriff auf die Ressource als Antwort auf eine Preflight-Anfrage erlaubten Methoden an.

Access-Control-Allow-Origin

Gibt an, ob die Antwort geteilt werden kann.

Access-Control-Expose-Headers

Gibt durch Auflisten ihrer Namen an, welche Header als Teil der Antwort offengelegt werden können.

Access-Control-Max-Age

Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage zwischengespeichert werden können.

Access-Control-Request-Headers

Wird beim Ausstellen einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden.

Access-Control-Request-Method

Wird beim Ausstellen einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Methode bei der eigentlichen Anfrage verwendet wird.

Origin

Gibt an, woher ein Fetch stammt.

Timing-Allow-Origin

Gibt Origins an, die Werte von Attributen sehen dürfen, die über Funktionen der Resource Timing API abgerufen wurden und aufgrund von Cross-Origin-Einschränkungen andernfalls als null gemeldet würden.

Downloads

Content-Disposition

Gibt an, ob die übertragene Ressource inline angezeigt werden soll (Standardverhalten ohne Header) oder ob sie wie ein Download behandelt werden soll und der Browser einen „Speichern unter“-Dialog anzeigen soll.

Integritäts-Digests

Content-Digest

Stellt einen Digest des in einer HTTP-Nachricht gerahmten Oktettstroms bereit (des Nachrichteninhalts), abhängig von Content-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 der Digest weder Content-Encoding noch Content-Range.

Want-Content-Digest

Äußert den Wunsch nach einem Header Content-Digest. Er ist das Content--Analogon von Want-Repr-Digest.

Want-Repr-Digest

Äußert den Wunsch nach einem Header Repr-Digest. Er ist das Repr--Analogon von Want-Content-Digest.

Integritätsrichtlinie

Integrity-Policy

Stellt sicher, dass alle Ressourcen, die der User-Agent lädt (eines bestimmten Typs), Subresource-Integrity-Garantien haben.

Integrity-Policy-Report-Only

Meldet Ressourcen, die der User-Agent lädt und die gegen Subresource-Integrity-Garantien verstoßen würden, wenn die Integritätsrichtlinie durchgesetzt würde (mithilfe des Headers Integrity-Policy).

Informationen zum Nachrichten-Body

Content-Length

Die Größe der Ressource als dezimale Anzahl von Bytes.

Content-Type

Gibt den Medientyp der Ressource an.

Content-Encoding

Wird verwendet, um den Komprimierungsalgorithmus anzugeben.

Content-Language

Beschreibt die für die Zielgruppe bestimmte(n) natürliche(n) Sprache(n), sodass ein Benutzer nach seiner eigenen bevorzugten Sprache unterscheiden kann.

Content-Location

Gibt einen alternativen Ort für die zurückgegebenen Daten an.

Nachrichtensignaturen

Accept-Signature

Der Header Accept-Signature fordert eine signierte Antwort oder nachfolgende Anfrage an und gibt die zu signierenden Komponenten und Signaturparameter an.

Signature

Der Header Signature enthält einen oder mehrere beschriftete Signaturwerte. Jede Beschriftung entspricht einem Eintrag in Signature-Input.

Signature-Input

Der Header Signature-Input identifiziert die geordnete Liste der von jeder Signatur abgedeckten Nachrichtenkomponenten sowie deren Metadaten, beispielsweise Erstellungszeit und Schlüsselkennung.

Hinweis: Diese Definitionen folgen RFC 9421. Der Entwurf zu Signed HTTP Exchanges (SXG) definiert ebenfalls Accept-Signature und Signature mit inkompatibler Semantik sowie einen eigenen Header Signed-Headers. Die einzige Browserimplementierung von SXG, Chromium, unterstützt diese jedoch nicht als HTTP-Header.

Präferenzen

Clients können Präferenzen in Anfragen senden, um optionale Verhaltensweisen für Anfragen und Antworten anzugeben. Die Serverantwort kann angeben, ob eine Präferenz angewendet wird, wenn dies andernfalls für den Client mehrdeutig wäre. Browser bieten keine native Unterstützung für das Senden von Präferenzen über diese Header; sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.

Prefer

Gibt Präferenzen für bestimmte Serververhaltensweisen während der Anfrageverarbeitung an. Beispielsweise kann minimaler Antwortinhalt (return=minimal) oder asynchrone Verarbeitung (respond-async) angefordert werden. Der Server verarbeitet die Anfrage normal, wenn der Header nicht unterstützt wird.

Preference-Applied

Informiert den Client darüber, welche im Header Prefer angegebenen Präferenzen vom Server angewendet wurden. Dies ist ein Header nur für Antworten, der Transparenz über die Behandlung von Präferenzen bietet.

Proxys

Forwarded

Enthält Informationen von der clientseitigen Seite von Proxyservern, die geändert werden oder verloren gehen, wenn ein Proxy am Pfad der Anfrage beteiligt ist.

Via

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

Bereichsanfragen

HTTP-Bereichsanfragen ermöglichen dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind für Anwendungen wie Mediaplayer nützlich, die Direktzugriff unterstützen, für Datenwerkzeuge, die wissen, dass sie nur einen Teil einer großen Datei benötigen, sowie für Download-Manager, die Benutzern das Anhalten und Fortsetzen eines Downloads ermöglichen.

Accept-Ranges

Gibt an, ob der Server Bereichsanfragen unterstützt und, falls ja, in welcher Einheit der Bereich ausgedrückt werden kann.

Range

Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.

If-Range

Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn der angegebene ETag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen zweier Bereiche aus inkompatiblen Versionen der Ressource zu verhindern.

Content-Range

Gibt an, an welcher Stelle in einer vollständigen Body-Nachricht eine Teilnachricht gehört.

Weiterleitungen

Location

Gibt die URL an, zu der eine Seite weitergeleitet werden soll.

Refresh

Weist den Browser an, die Seite neu zu laden oder zu einer anderen weiterzuleiten. Akzeptiert denselben Wert wie das Element meta mit http-equiv="refresh".

Anfragekontext

From

Enthält eine Internet-E-Mail-Adresse eines menschlichen Benutzers, der den anfragenden User-Agent steuert.

Host

Gibt den Domainnamen des Servers (für virtuelles Hosting) und optional die TCP-Portnummer an, auf der der Server lauscht.

Referer

Die Adresse der vorherigen Webseite, von der aus ein Link zur aktuell angeforderten Seite gefolgt wurde.

Referrer-Policy

Legt fest, welche Referrer-Informationen, die im Header Referer gesendet werden, in ausgeführten Anfragen enthalten sein sollen.

User-Agent

Enthält eine charakteristische Zeichenfolge, die es Netzwerkprotokoll-Gegenstellen ermöglicht, Anwendungstyp, Betriebssystem, Softwareanbieter oder Softwareversion des anfragenden Software-User-Agents zu identifizieren.

Antwortkontext

Allow

Listet die Menge der von einer Ressource unterstützten HTTP-Anfragemethoden auf.

Server

Enthält Informationen über die vom Origin-Server verwendete Software zur Verarbeitung der Anfrage.

Sicherheit

Cross-Origin-Embedder-Policy (COEP)

Ermöglicht einem Server, eine Embedder-Richtlinie für ein bestimmtes Dokument zu deklarieren.

Cross-Origin-Opener-Policy (COOP)

Verhindert, dass andere Domains ein Fenster öffnen oder steuern.

Cross-Origin-Resource-Policy (CORP)

Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch den erklärenden Artikel zu CORP.

Content-Security-Policy (CSP)

Steuert, welche Ressourcen der User-Agent für eine bestimmte Seite laden darf.

Content-Security-Policy-Report-Only

Ermöglicht Webentwicklern, mit Richtlinien zu experimentieren, indem deren Auswirkungen überwacht, aber nicht durchgesetzt werden. Diese Verletzungsberichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.

Expect-CT

Ermöglicht Websites die Teilnahme an der Meldung und Durchsetzung von Certificate Transparency, um die Verwendung falsch ausgestellter Zertifikate für diese Website zu erkennen.

Permissions-Policy

Bietet einen Mechanismus zum Erlauben und Verweigern der Nutzung von Browserfunktionen im eigenen Frame einer Website sowie in eingebetteten <iframe>s.

Reporting-Endpoints

Antwort-Header, der Websiteinhabern erlaubt, einen oder mehrere Endpunkte anzugeben, die zum Empfang von Fehlern wie CSP-Verletzungsberichten, Cross-Origin-Opener-Policy-Berichten oder anderen allgemeinen Verletzungen verwendet werden.

Strict-Transport-Security (HSTS)

Erzwingt Kommunikation über HTTPS statt über HTTP.

Upgrade-Insecure-Requests

Sendet ein Signal an den Server, das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt und angibt, dass dieser die Direktive upgrade-insecure-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> rendern darf.

X-Permitted-Cross-Domain-Policies

Eine Cross-Domain-Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domains hinweg zu verarbeiten, die andernfalls aufgrund der Same-Origin-Policy eingeschränkt wären. Der Header X-Permitted-Cross-Domain-Policies überschreibt solche Richtliniendateien, sodass Clients unerwünschte Anfragen weiterhin blockieren.

X-Powered-By

Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen darüber, ohne der Anwendung oder ihren Besuchern einen Nutzen zu bieten. Entfernen Sie diesen Header, um die Offenlegung potenzieller Sicherheitslücken zu vermeiden.

X-XSS-Protection

Aktiviert Cross-Site-Scripting-Filterung.

Fetch-Metadaten-Anfrage-Header

Fetch-Metadaten-Anfrage-Header stellen Informationen über den Kontext bereit, aus dem die Anfrage stammt. Ein Server kann sie verwenden, um Entscheidungen darüber zu treffen, ob eine Anfrage erlaubt werden soll, basierend darauf, woher die Anfrage stammt und wie die Ressource verwendet wird.

Sec-Fetch-Site

Gibt die Beziehung zwischen der Origin des Anfrageinitiators und der Origin des Ziels an. Es ist ein Structured Header, dessen Wert ein Token mit den möglichen Werten cross-site, same-origin, same-site und none ist.

Sec-Fetch-Mode

Gibt einem Server den Modus der Anfrage an. Es ist ein Structured Header, dessen Wert ein Token mit den möglichen Werten cors, navigate, no-cors, same-origin und websocket ist.

Sec-Fetch-User

Gibt an, ob eine Navigationsanfrage durch eine Benutzeraktivierung ausgelöst wurde. Es ist ein Structured Header, dessen Wert ein boolescher Wert ist; mögliche Werte sind daher ?0 für falsch und ?1 für wahr.

Sec-Fetch-Dest

Gibt das Ziel der Anfrage an. Es ist ein Structured Header, dessen Wert ein Token mit den möglichen Werten audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker und xslt ist.

Die folgenden Anfrage-Header sind nicht streng genommen „Fetch-Metadaten-Anfrage-Header“, stellen jedoch ähnlich Informationen über den Kontext bereit, in dem eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten oder die zurückgegebenen Informationen zu ändern:

Sec-Purpose

Gibt den Zweck der Anfrage an, wenn dieser Zweck nicht die unmittelbare Verwendung durch den User-Agent ist. Der Header hat derzeit einen möglichen Wert, prefetch, der angibt, dass die Ressource vorsorglich für eine mögliche zukünftige Navigation abgerufen wird.

Service-Worker-Navigation-Preload

Ein Anfrage-Header, der in einer vorsorglichen Anfrage gesendet wird, um während des Starts eines Service Workers eine Ressource mit fetch() abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource als bei einem normalen fetch()-Vorgang zurückgegeben werden soll.

Fetch-Speicherzugriffs-Header

Diese Header ermöglichen einen erweiterten Workflow für die Storage Access API.

Sec-Fetch-Storage-Access

Gibt den „Speicherzugriffsstatus“ für den aktuellen Fetch-Kontext an, der entweder none, inactive oder active ist. Der Server kann mit Activate-Storage-Access antworten, um anzufordern, dass der Browser eine Berechtigung mit dem Status inactive aktiviert und die Anfrage wiederholt, oder um eine Ressource mit Zugriff auf ihre Drittanbieter-Cookies zu laden, wenn der Status active ist.

Activate-Storage-Access

Wird als Antwort auf Sec-Fetch-Storage-Access verwendet, um anzugeben, dass der Browser eine vorhandene Berechtigung für sicheren Zugriff aktivieren und die Anfrage mit Cookies wiederholen kann oder eine Ressource mit Cookie-Zugriff laden kann, wenn bereits eine aktivierte Berechtigung vorhanden ist.

Servergesendete Ereignisse

Reporting-Endpoints

Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser bei Verwendung der Reporting API Warnungs- und Fehlerberichte senden soll.

Report-To

Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser bei Verwendung der Reporting API Warnungs- und Fehlerberichte senden soll.

Übertragungskodierung

Transfer-Encoding

Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.

TE

Gibt die Übertragungskodierungen an, die der User-Agent akzeptieren möchte.

Trailer

Ermöglicht dem Absender, am Ende einer in Chunks übertragenen Nachricht zusätzliche Felder einzuschließen.

WebSockets

Header, die von der WebSockets API im WebSocket-Handshake verwendet werden:

Sec-WebSocket-Accept

Antwort-Header, der angibt, dass der Server bereit ist, auf eine WebSocket-Verbindung hochzustufen.

Sec-WebSocket-Extensions

In Anfragen gibt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten gibt er die vom Server aus den Präferenzen des Clients ausgewählte Erweiterung an.

Sec-WebSocket-Key

Anfrage-Header, der einen Schlüssel enthält, der bestätigt, dass der Client ausdrücklich beabsichtigt, einen WebSocket zu öffnen.

Sec-WebSocket-Protocol

In Anfragen gibt dieser Header die vom Client unterstützten Unterprotokolle in bevorzugter Reihenfolge an. In Antworten gibt er das vom Server aus den Präferenzen des Clients ausgewählte Unterprotokoll an.

Sec-WebSocket-Version

In Anfragen gibt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn die angeforderte Protokollversion vom Server nicht unterstützt wird, und listet die vom Server unterstützten Versionen auf.

Sonstiges

Alt-Svc

Wird verwendet, um alternative Wege zum Erreichen dieses Dienstes aufzulisten.

Alt-Used

Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.

Date

Enthält das Datum und die Uhrzeit, zu denen die Nachricht erstellt wurde.

Dieses Entity-Header-Feld bietet eine Möglichkeit, einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML-Element <link>.

Retry-After

Gibt an, wie lange der User-Agent warten soll, bevor er eine Folgeanfrage stellt.

Server-Timing

Übermittelt eine oder mehrere Metriken und Beschreibungen für den angegebenen Anfrage-Antwort-Zyklus.

Service-Worker

Wird in Fetches für die Skriptressource eines Service Workers eingeschlossen. Dieser Header hilft Administratoren dabei, Anfragen für Service-Worker-Skripte zu Überwachungszwecken zu protokollieren.

Service-Worker-Allowed

Wird verwendet, um die Pfadbeschränkung aufzuheben, indem dieser Header in die Antwort des Service-Worker-Skripts aufgenommen wird.

SourceMap

Verlinkt auf eine Source Map, sodass Debugger den ursprünglichen Quellcode statt generierten oder transformierten Code schrittweise durchlaufen können.

Upgrade

Dieser Header (nur HTTP/1.1) kann verwendet werden, um eine bereits aufgebaute Client-Server-Verbindung auf ein anderes Protokoll hochzustufen (über dasselbe Transportprotokoll). Beispielsweise kann ein Client damit eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- bzw. HTTPS-Verbindung auf einen WebSocket hochstufen.

Priority

Liefert einen Hinweis zur Priorität einer bestimmten Ressourcenanfrage auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzugeben, oder in einer Antwort, wenn der Server die Anfrage neu priorisieren möchte.

Experimentelle Header

Attribution-Reporting-Header

Die Attribution Reporting API ermöglicht Entwicklern, Conversions zu messen — beispielsweise wenn ein Benutzer auf eine auf einer Website eingebettete Anzeige klickt und das Produkt anschließend auf der Website des Anbieters kauft — und anschließend auf Berichte zu diesen Conversions zuzugreifen. Dies geschieht ohne Abhängigkeit von Drittanbieter-Tracking-Cookies, indem stattdessen verschiedene Header verwendet werden, um Quellen und Trigger zu registrieren, die zur Kennzeichnung einer Conversion abgeglichen werden.

Attribution-Reporting-Eligible

Wird verwendet, um anzugeben, dass die der aktuellen Anfrage entsprechende Antwort zur Teilnahme am Attribution Reporting berechtigt ist, indem entweder eine Attributionsquelle oder ein Attributions-Trigger registriert wird.

Attribution-Reporting-Register-Source

Wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen Header Attribution-Reporting-Eligible enthielt, und dient zum Registrieren einer Attributionsquelle.

Attribution-Reporting-Register-Trigger

Wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen Header Attribution-Reporting-Eligible enthielt, und dient zum Registrieren eines Attributions-Triggers.

Client Hints

HTTP-Client Hints sind eine Gruppe von Anfrage-Headern, die nützliche Informationen über den Client bereitstellen, etwa Gerätetyp und Netzwerkbedingungen, und es Servern ermöglichen, die unter diesen Bedingungen bereitgestellten Inhalte zu optimieren.

Server fordern die Client-Hint-Header, an denen sie interessiert sind, proaktiv mit Accept-CH vom Client an. Der Client kann dann entscheiden, die angeforderten Header in nachfolgenden Anfragen einzuschließen.

Accept-CH

Server können Unterstützung für Client Hints mit dem Headerfeld Accept-CH oder einem äquivalenten HTML-Element <meta> mit dem Attribut http-equiv ankündigen.

Critical-CH

Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client Hints auch kritische Client Hints sind.

Die verschiedenen Kategorien von Client Hints sind unten aufgeführt.

User-Agent-Client-Hints

Die UA-Client-Hints sind Anfrage-Header, die Informationen über den User-Agent, die Plattform/Architektur, auf der er ausgeführt wird, sowie Benutzereinstellungen bereitstellen, die im User-Agent oder auf der Plattform festgelegt sind:

Sec-CH-UA

Branding und Version des User-Agents.

Sec-CH-UA-Arch

Zugrunde liegende Plattformarchitektur des User-Agents.

Sec-CH-UA-Bitness

Bitbreite der zugrunde liegenden CPU-Architektur des User-Agents, beispielsweise „64“ Bit.

Sec-CH-UA-Form-Factors

Formfaktoren des User-Agents, die beschreiben, wie der Benutzer mit dem User-Agent interagiert.

Sec-CH-UA-Full-Version

Vollständige Versionszeichenfolge des User-Agents.

Sec-CH-UA-Full-Version-List

Vollständige Version für jede Marke in der Markenliste des User-Agents.

Sec-CH-UA-Mobile

Der User-Agent läuft auf einem Mobilgerät oder bevorzugt allgemeiner eine „mobile“ Benutzererfahrung.

Sec-CH-UA-Model

Gerätemodell des User-Agents.

Sec-CH-UA-Platform

Zugrunde liegendes Betriebssystem bzw. Plattform des User-Agents.

Sec-CH-UA-Platform-Version

Version des zugrunde liegenden Betriebssystems des User-Agents.

Sec-CH-UA-WoW64

Gibt an, ob die Binärdatei des User-Agents unter 64-Bit-Windows im 32-Bit-Modus ausgeführt wird.

Sec-CH-Prefers-Color-Scheme

Präferenz des Benutzers für ein dunkles oder helles Farbschema.

Sec-CH-Prefers-Reduced-Motion

Präferenz des Benutzers, weniger Animationen und Verschiebungen des Inhaltslayouts zu sehen.

Sec-CH-Prefers-Reduced-Transparency

Anfrage-Header, der die Präferenz des User-Agents für verringerte Transparenz angibt.

Hinweis: User-Agent-Client-Hints sind innerhalb von Fenced Frames nicht verfügbar, da sie auf der Delegierung von Permissions Policy beruhen, die zum Offenlegen von Daten verwendet werden könnte.

Geräte- und responsive Bild-Client-Hints

Sec-CH-Device-Memory

Ungefähre Menge des verfügbaren RAM-Speichers des Clients. Dies ist Teil der Device Memory API.

Sec-CH-DPR

Anfrage-Header, der das Gerätepixelverhältnis des Clients bereitstellt, also die Anzahl physischer Gerätepixel pro CSS-Pixel.

Sec-CH-Viewport-Height

Anfrage-Header, der die Höhe des Layout-Viewports des Clients in CSS-Pixeln bereitstellt.

Sec-CH-Viewport-Width

Anfrage-Header, der die Breite des Layout-Viewports des Clients in CSS-Pixeln bereitstellt.

Sec-CH-Width

Anfrage-Header, der die Breite des Bildes in CSS-Pixeln bereitstellt.

Veraltete Geräte- und responsive Bild-Client-Hints
Device-Memory

Standardisiert als Sec-CH-Device-Memory

DPR

Standardisiert als Sec-CH-DPR

Viewport-Width

Standardisiert als Sec-CH-Viewport-Width

Width

Standardisiert als Sec-CH-Width

Netzwerk-Client-Hints

Netzwerk-Client-Hints ermöglichen es einem Server, anhand der Benutzerauswahl sowie der Netzwerkbandbreite und -latenz zu bestimmen, welche Informationen gesendet werden.

Ungefähre Bandbreite der Verbindung des Clients zum Server in Mbps. Dies ist Teil der Network Information API.

ECT

Der effektive Verbindungstyp („Netzwerkprofil“), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.

RTT

Round-Trip-Time (RTT) der Anwendungsschicht in Millisekunden, einschließlich der Verarbeitungszeit des Servers. Dies ist Teil der Network Information API.

Save-Data

Eine Zeichenfolge on, die die Präferenz des User-Agents für einen reduzierten Datenverbrauch angibt.

Compression Dictionary Transport

Compression Dictionary Transport ist eine Methode zur Verwendung eines gemeinsam genutzten Komprimierungswörterbuchs, um die Übertragungsgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch in der Brotli-Komprimierung oder der Zstandard-Komprimierung zu verwenden.

Available-Dictionary

Ein Browser kann diesen Anfrage-Header verwenden, um das beste verfügbare Wörterbuch anzugeben, das der Server zur Komprimierung verwenden kann.

Dictionary-ID

Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource verfügbar hat und der Server im Header Use-As-Dictionary eine id für das Wörterbuch bereitgestellt hat. Anfragen für Ressourcen, die das Wörterbuch verwenden können, haben einen Header Available-Dictionary sowie die vom Server bereitgestellte Wörterbuch-id im Header Dictionary-ID.

Use-As-Dictionary

Listet die Abgleichkriterien auf, für die das Wörterbuch in zukünftigen Anfragen verwendet werden kann.

Datenschutz

DNT

Anfrage-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Zugunsten von Global Privacy Control (GPC) veraltet, das Servern über den Header Sec-GPC mitgeteilt wird und für Clients über navigator.globalPrivacyControl zugänglich ist.

Tk

Antwort-Header, der den Tracking-Status angibt, der für die entsprechende Anfrage galt. Wird zusammen mit DNT verwendet.

Sec-GPC

Gibt an, ob der Benutzer damit einverstanden ist, dass eine Website oder ein Dienst seine personenbezogenen Daten an Dritte verkauft oder weitergibt.

Sicherheit

Origin-Agent-Cluster

Antwort-Header, der verwendet wird, um anzugeben, dass das zugehörige Document in einem Origin-gebundenen Agent-Cluster platziert werden soll. Diese Isolation ermöglicht es User-Agents, implementierungsspezifische Ressourcen für Agent-Cluster, beispielsweise Prozesse oder Threads, effizienter zuzuweisen.

Servergesendete Ereignisse

NEL

Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Richtlinie zur Meldung von Netzwerkfehlern zu deklarieren.

Topics API

Die Topics API stellt Entwicklern einen Mechanismus zur Implementierung von Anwendungsfällen wie interessenbasierter Werbung (IBA) bereit. Weitere Informationen finden Sie in der Dokumentation zur Topics API.

Observe-Browsing-Topics

Antwort-Header, der verwendet wird, um Interessenthemen, die aus der URL einer aufrufenden Website abgeleitet wurden, als in der Antwort auf eine durch eine Funktion zur Aktivierung der Topics API erzeugte Anfrage beobachtet zu markieren.

Sec-Browsing-Topics

Anfrage-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet. Diese werden von einer Ad-Tech-Plattform verwendet, um eine personalisierte anzuzeigende Anzeige auszuwählen.

Sonstiges

Early-Data

Gibt an, dass die Anfrage in TLS Early Data übermittelt wurde.

Idempotency-Key

Stellt einen eindeutigen Schlüssel für POST- und PATCH-Anfragen bereit, sodass diese idempotent ausgeführt werden können.

Set-Login

Antwort-Header, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, also ob auf dem aktuellen Browser Benutzer beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM API verwendet.

Speculation-Rules

Stellt eine Liste von URLs bereit, die auf Textressourcen mit Speculation-Rule-JSON-Definitionen verweisen. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Speculation-Rule-Set des Dokuments hinzugefügt.

Sec-Speculation-Tags

Enthält einen oder mehrere Tag-Werte aus den Speculation Rules, die zu der Spekulation geführt haben, damit ein Server erkennen kann, welche Regel(n) eine Spekulation verursacht haben, und sie gegebenenfalls blockieren kann.

Supports-Loading-Mode

Wird von einem Navigationsziel gesetzt, um sich für die Verwendung verschiedener Lademodi mit höherem Risiko anzumelden. Beispielsweise erfordert Cross-Origin-, Same-Site-Prerendering einen Wert von credentialed-prerender für Supports-Loading-Mode.

Nicht standardisierte Header

X-Forwarded-For

Identifiziert die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder einen Load Balancer eine Verbindung zu einem Webserver herstellt.

X-Forwarded-Host

Identifiziert den ursprünglich angeforderten Host, den ein Client für die Verbindung zu Ihrem Proxy oder Load Balancer verwendet hat.

X-Forwarded-Proto

Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client für die Verbindung zu Ihrem Proxy oder Load Balancer verwendet hat.

X-DNS-Prefetch-Control

Steuert DNS-Prefetching, eine Funktion, mit der Browser proaktiv die Auflösung von Domainnamen sowohl für Links durchführen, denen der Benutzer möglicherweise folgen möchte, als auch für URLs von Elementen, auf die das Dokument verweist, einschließlich Bildern, CSS, JavaScript usw.

X-Robots-Tag

Der HTTP-Header X-Robots-Tag wird verwendet, um anzugeben, wie eine Webseite in öffentlichen Suchmaschinenergebnissen indexiert werden soll. Der Header entspricht Elementen <meta name="robots">.

Veraltete Header

Pragma

Implementierungsspezifischer Header, der überall entlang der Anfrage-Antwort-Kette verschiedene Auswirkungen haben kann. Wird zur Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, bei denen der Header Cache-Control noch nicht vorhanden ist.

Warning

Allgemeine Warninformationen über mögliche Probleme.

Siehe auch