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 Berücksichtigung der Groß- und Kleinschreibung, gefolgt von einem Doppelpunkt, anschließend optionalen Leerzeichen, die ignoriert werden, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header bei der Anzeige in Entwicklertools kleingeschrieben (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 in der Vergangenheit mit dem Präfix X- verwendet, aber diese Konvention wurde 2012 aufgrund der Schwierigkeiten, die sie verursachte, wenn nicht standardisierte Felder in RFC 6648 standardisiert wurden, als veraltet eingestuft; andere sind in der IANA-Registrierung für HTTP-Feldnamen aufgeführt, deren ursprünglicher Inhalt in RFC 4229 definiert wurde. Die IANA-Registrierung führt Header auf, einschließlich Informationen zu ihrem Status.

Header können nach ihren Kontexten 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 Speicherort 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: an den Server bei einer Anfrage oder an den Client bei einer Antwort. Zwischenliegende Proxys müssen diese Header unverändert erneut übertragen 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 erneut übertragen oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mit dem Header Connection gesetzt 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 gegenüber einem Server.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die für den Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden soll.
Proxy-Authorization: Enthält die Anmeldedaten zur Authentifizierung eines User-Agents gegenüber einem Proxy-Server.

Caching

Age: Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache verbracht hat.
Cache-Control: Direktiven für Caching-Mechanismen in Anfragen und Antworten.
Clear-Site-Data: Löscht Browsing-Daten (z. B. Cookies, Speicher, Cache), die der anfragenden Website zugeordnet sind.
Expires: Das Datum/die Uhrzeit, nach dem bzw. der die Antwort als veraltet gilt.
No-Vary-Search: 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 Vergleichen mehrerer Versionen derselben Ressource verwendet wird. Es ist weniger genau als ETag, in einigen Umgebungen aber einfacher zu 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 das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine vorhanden ist.
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 Konsistenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen Fragmenten sicher oder implementiert beim Ändern bestehender Dokumente ein optimistisches Nebenläufigkeitskontrollsystem.
Vary: Bestimmt, wie Anfrage-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine aktuelle Antwort 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 Details finden Sie im Artikel zur Inhaltsaushandlung.

Accept: Informiert den Server über die Datentypen, die 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: Informiert den Server über die menschliche Sprache, die der Server voraussichtlich zurücksenden soll. Dies ist ein Hinweis und liegt nicht zwingend vollständig unter der Kontrolle des Benutzers: Der Server sollte stets darauf achten, keine ausdrückliche Benutzerwahl zu überschreiben, etwa die Auswahl einer Sprache aus einer Dropdown-Liste.
Accept-Patch: Ein Antwort-Header für Inhaltsaushandlung bei Anfragen, der bekannt gibt, welchen Medientyp der Server in einer PATCH-Anfrage verstehen kann.
Accept-Post: Ein Antwort-Header für Inhaltsaushandlung bei Anfragen, der bekannt gibt, welchen Medientyp der Server in einer POST-Anfrage verstehen kann.

Steuerung

Expect: Gibt Erwartungen an, die vom Server erfüllt werden müssen, damit er die Anfrage korrekt verarbeiten kann.
Max-Forwards: Gibt bei der Verwendung von TRACE die maximale Anzahl von Hops an, die die Anfrage durchführen kann, bevor sie an den Absender zurückgespiegelt wird.

Cookies

Cookie: Enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem Header Set-Cookie gesendet wurden.
Set-Cookie: 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 true ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header beim Stellen 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 Ausgeben einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Header beim Stellen der eigentlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird beim Ausgeben einer Preflight-Anfrage verwendet, um den Server darüber zu informieren, welche HTTP-Methode beim Stellen 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 die andernfalls aufgrund von Cross-Origin-Einschränkungen als null gemeldet würden.

Downloads

Content-Disposition: Gibt an, ob die übertragene Ressource inline angezeigt werden soll (Standardverhalten ohne den 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 bei Content-Digest berücksichtigt der Digest weder Content-Encoding noch Content-Range.
Want-Content-Digest: Drückt den Wunsch nach einem Header Content-Digest aus. Er ist das Content--Analogon von Want-Repr-Digest.
Want-Repr-Digest: Drückt den Wunsch nach einem Header Repr-Digest aus. 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), Garantien für Subresource Integrity aufweisen.
Integrity-Policy-Report-Only: Meldet Ressourcen, die der User-Agent lädt und die Garantien für Subresource Integrity verletzen 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 das Publikum bestimmte(n) menschliche(n) Sprache(n), sodass ein Benutzer nach seiner eigenen bevorzugten Sprache unterscheiden kann.
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 nachfolgende Anfrage an und gibt die zu signierenden Komponenten sowie Signaturparameter an.
Signature: Der Header Signature enthält einen oder mehrere beschriftete Signaturwerte. Jede Bezeichnung entspricht einem Eintrag in Signature-Input.
Signature-Input: Der Header Signature-Input identifiziert die geordnete Liste der von jeder Signatur abgedeckten Nachrichtenkomponenten und ihrer Metadaten, etwa 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

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

Prefer: Gibt Präferenzen für bestimmte Serververhalten 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 reiner Antwort-Header, der Transparenz über die Behandlung von Präferenzen bietet.

Proxys

Forwarded: Enthält Informationen von der dem Client zugewandten Seite von Proxy-Servern, die verändert werden oder verloren gehen, wenn ein Proxy am Pfad der Anfrage beteiligt ist.
Via: Wird von Proxys, sowohl Forward- als auch Reverse-Proxys, hinzugefügt und kann in Anfrage-Headern und Antwort-Headern erscheinen.

Bereichsanfragen

HTTP-Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Media-Player, die wahlfreien Zugriff unterstützen, Datenwerkzeuge, die nur einen Teil einer großen Datei benötigen, und Download-Manager, mit denen Benutzer einen Download anhalten und fortsetzen können.

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 Remote-Ressource übereinstimmt. Wird verwendet, um das Herunterladen zweier Bereiche aus inkompatiblen Versionen der Ressource zu verhindern.
Content-Range: Gibt an, an welcher Stelle 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 einem Link zur aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy: Steuert, welche Referrer-Informationen, die im Header Referer gesendet werden, in gestellten Anfragen enthalten sein sollen.
User-Agent: Enthält eine charakteristische Zeichenfolge, die es den Netzwerkprotokollpartnern ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die 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 Software, die der Origin-Server zur Verarbeitung der Anfrage verwendet.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht einem Server, eine Einbettungsrichtlinie 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 von Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch den CORP-Erklärartikel.
Content-Security-Policy (CSP): Steuert die Ressourcen, die 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, sich für die Meldung und Durchsetzung von Certificate Transparency zu entscheiden, um die Verwendung fehlerhaft ausgestellter Zertifikate für diese Website zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Verwendung von Browserfunktionen im eigenen Frame einer Website und in eingebetteten <iframe>s zu erlauben oder zu verweigern.
Reporting-Endpoints: Antwort-Header, mit dem Websiteinhaber einen oder mehrere Endpunkte angeben können, die zum Empfangen von Fehlern wie CSP-Verletzungsberichten, Berichten zu Cross-Origin-Opener-Policy oder anderen allgemeinen Verletzungen verwendet werden.
Strict-Transport-Security (HSTS): Erzwingt Kommunikation über HTTPS statt HTTP.
Upgrade-Insecure-Requests: Sendet dem Server ein Signal, das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt, und dass er 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-Policy-Datei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domains hinweg zu verarbeiten, die ansonsten aufgrund der Same-Origin Policy eingeschränkt wären. Der Header X-Permitted-Cross-Domain-Policies überschreibt solche Policy-Dateien, sodass Clients unerwünschte Anfragen weiterhin blockieren.
X-Powered-By: Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, 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 anhand des Ursprungs der Anfrage und der beabsichtigten Verwendung der Ressource zu entscheiden, ob eine Anfrage erlaubt werden soll.

Sec-Fetch-Site: Gibt die Beziehung zwischen der Origin eines Anfrageinitiators und der Origin seines 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 false und ?1 für true.
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 aber ähnlich Informationen über den Kontext bereit, wie eine Ressource verwendet werden soll. 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 der Zweck nicht die unmittelbare Nutzung 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 zum fetch() einer Ressource während des Starts eines Service Workers gesendet wird. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource zurückgegeben werden soll als bei einer normalen fetch()-Operation.

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 none, inactive oder active ist. Der Server kann mit Activate-Storage-Access antworten, um anzufordern, dass der Browser eine Berechtigung mit Status inactive aktiviert und die Anfrage wiederholt, oder eine Ressource mit Zugriff auf ihre Third-Party-Cookies lädt, 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.

Vom Server gesendete Ereignisse

Reporting-Endpoints: Antwort-Header zur Angabe von Serverendpunkten, an die der Browser bei Verwendung der Reporting API Warn- und Fehlerberichte senden soll.
Report-To: Antwort-Header zur Angabe von Serverendpunkten, an die der Browser bei Verwendung der Reporting API Warn- und Fehlerberichte senden soll.

Transferkodierung

Transfer-Encoding: Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.
TE: Gibt die Transferkodierungen 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 mit einem Schlüssel, der bestätigt, dass der Client ausdrücklich beabsichtigt, eine WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die vom Client unterstützten Subprotokolle in bevorzugter Reihenfolge an. In Antworten gibt er das vom Server aus den Präferenzen des Clients ausgewählte Subprotokoll 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 Möglichkeiten zum Erreichen dieses Dienstes aufzulisten.
Alt-Used: Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.
Date: Enthält Datum und Uhrzeit, zu denen die Nachricht erstellt wurde.
Link: Dieses Entity-Header-Feld stellt ein Mittel bereit, um 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 nach Service-Worker-Skripten 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: Verweist auf eine Source Map, sodass Debugger den ursprünglichen Quellcode statt generiertem oder transformiertem Code schrittweise durchlaufen können.
Upgrade: Dieser Header, der nur in HTTP/1.1 verfügbar ist, kann verwendet werden, um eine bereits hergestellte Client-/Serververbindung auf ein anderes Protokoll hochzustufen (über dasselbe Transportprotokoll). Beispielsweise kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- oder HTTPS-Verbindung auf WebSocket hochzustufen.
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 sich dafür entscheidet, die Anfrage neu zu priorisieren.

Experimentelle Header

Header für Attribution Reporting

Die Attribution Reporting API ermöglicht Entwicklern, Conversions zu messen — beispielsweise wenn ein Benutzer auf eine auf einer Website eingebettete Anzeige klickt und dann den Artikel auf der Website des Verkäufers kauft — und anschließend auf Berichte über diese Conversions zuzugreifen. Dies geschieht ohne Third-Party-Tracking-Cookies, stattdessen werden verschiedene Header verwendet, um Quellen und Trigger zu registrieren, die abgeglichen werden, um eine Conversion anzuzeigen.

Attribution-Reporting-Eligible: Wird verwendet, um anzugeben, dass die Antwort auf die aktuelle Anfrage berechtigt ist, an Attribution Reporting teilzunehmen, indem entweder eine Attributionsquelle oder ein 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 Attributionstriggers.

Client Hints

HTTP-Client Hints sind eine Reihe von Anfrage-Headern, die nützliche Informationen über den Client bereitstellen, etwa Gerätetyp und Netzwerkbedingungen, und Servern ermöglichen, das Bereitgestellte für diese Bedingungen zu optimieren.

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

Accept-CH: Server können mithilfe des Header-Felds Accept-CH oder eines entsprechenden HTML-Elements <meta> mit dem Attribut http-equiv Unterstützung für Client Hints bekannt geben.
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 im User-Agent oder auf der Plattform festgelegte Benutzerpräferenzen bereitstellen:

Sec-CH-UA: Branding und Version des User-Agents.
Sec-CH-UA-Arch: Zugrunde liegende Plattformarchitektur des User-Agents.
Sec-CH-UA-Bitness: Bitness der zugrunde liegenden CPU-Architektur des User-Agents (zum Beispiel „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/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 im 32-Bit-Modus auf 64-Bit-Windows 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 Content-Layouts zu sehen.
Sec-CH-Prefers-Reduced-Transparency: Anfrage-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, weil 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 Device Pixel Ratio des Clientgeräts bereitstellt (die Anzahl physischer Gerätepixel für jeden 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 einem Server, anhand der Benutzerwahl sowie der Netzwerkbandbreite und -latenz zu wählen, welche Informationen gesendet werden.

Downlink: 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 Anwendungsebene 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 eine reduzierte Datennutzung angibt.

Compression Dictionary Transport

Compression Dictionary Transport ist eine Methode, ein gemeinsames Komprimierungswörterbuch zu verwenden, um die Übertragungsgröße von HTTP-Antworten zu reduzieren, statt 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 ihm 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 nach Ressourcen, die das Wörterbuch verwenden können, enthalten 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). Veraltet zugunsten von Global Privacy Control (GPC), 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 auf die entsprechende Anfrage angewendet wurde. Wird zusammen mit DNT verwendet.
Sec-GPC: Gibt an, ob der Benutzer einer Website oder einem Dienst zustimmt, seine persönlichen Informationen an Dritte zu verkaufen oder weiterzugeben.

Sicherheit

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

Vom Server gesendete Ereignisse

NEL: Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Richtlinie für die Meldung von Netzwerkfehlern zu deklarieren.

Topics API

Die Topics API bietet Entwicklern einen Mechanismus, um Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. 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 für den aktuellen Benutzer ausgewählten Themen zusammen mit der zugehörigen Anfrage sendet, damit eine Werbetechnologieplattform eine personalisierte Anzeige zur Darstellung auswählen kann.

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, wodurch 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 aktuell Benutzer im IdP im Browser angemeldet sind oder nicht. Dieser wird vom Browser gespeichert und von der FedCM API verwendet.
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 Speculation-Rule-Satz 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, sodass 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 zu entscheiden. Beispielsweise erfordert Cross-Origin-, Same-Site-Prerendering einen Wert 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 Load Balancer eine Verbindung mit einem Webserver herstellt.
X-Forwarded-Host: Identifiziert den ursprünglich angeforderten Host, den ein Client für die Verbindung mit Ihrem Proxy oder Load Balancer verwendet hat.
X-Forwarded-Proto: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client für die Verbindung mit Ihrem Proxy oder Load Balancer verwendet hat.
X-DNS-Prefetch-Control: Steuert DNS-Prefetching, eine Funktion, durch die Browser proaktiv die Auflösung von Domainnamen für Links durchführen, denen der Benutzer möglicherweise folgen möchte, sowie 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 an jeder Stelle der Anfrage-Antwort-Kette verschiedene Auswirkungen haben kann. Wird für 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

Help improve MDN

Erfahren Sie, wie Sie beitragen können Diese Seite wurde automatisch aus dem Englischen übersetzt.

Übersetzung auf GitHub anzeigen • Fehler mit dieser Übersetzung melden