HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort zu übermitteln. In HTTP/1.X ist ein Header ein nicht unterscheidungssensitiver Name gefolgt von einem Doppelpunkt, dann optionalen Leerzeichen, die ignoriert werden, und schließlich von seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header in Kleinbuchstaben angezeigt, wenn sie in Entwicklertools betrachtet werden (accept: */*), und mit einem Doppelpunkt für eine spezielle Gruppe von Pseudo-Headern (:status: 200) versehen. Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden historisch mit einem X- Präfix verwendet, aber diese Konvention wurde 2012 aufgrund der Unannehmlichkeiten, die sie verursachte, wenn nicht standardisierte Felder in RFC 6648 standardisiert wurden, eingestellt; andere sind im IANA HTTP Field Name Registry aufgelistet, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status.

Header können entsprechend ihrer Kontexte gruppiert werden:

Anforderungsheader

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

Antwort-Header

Enthalten zusätzliche Informationen über die Antwort, wie zum Beispiel ihren Standort oder den Server, der sie bereitstellt.

Darstellungs-Header

Enthalten Informationen über den Körper der Ressource, wie ihren MIME-Typ oder die angewandte Kodierung/Kompression.

Payload-Header

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

Header können auch entsprechend der Handhabung durch Proxies gruppiert werden:

Ende-zu-Ende-Header

Diese Header müssen an den endgültigen Empfänger der Nachricht gesendet werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenproxies 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 Transportverbindung bedeutend und dürfen nicht von Proxies weitergeleitet oder gecacht werden. Beachten Sie, dass nur Hop-by-Hop-Header mithilfe des Connection Headers festgelegt werden dürfen.

Authentifizierung

WWW-Authenticate

Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource zuzugreifen.

Authorization

Enthält die Anmeldedaten, um einen User-Agent bei einem Server zu authentifizieren.

Proxy-Authenticate

Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource hinter einem Proxy-Server zuzugreifen.

Proxy-Authorization

Enthält die Anmeldedaten, um einen User-Agent bei einem Proxy-Server zu authentifizieren.

Caching

Age

Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache war.

Cache-Control

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

Clear-Site-Data

Löscht Browserdaten (z. B. Cookies, Speicher, Cache), die mit der anfordernden Website verknüpft sind.

Expires

Das Datum/Zeit, nach dem die Antwort als veraltet angesehen wird.

Gibt einen Satz von Regeln an, die bestimmen, wie die Abfrageparameter einer URL das Cache-Matching beeinflussen. Diese Regeln bestimmen, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Bedingte Anfragen

Last-Modified

Das Datum der letzten Änderung der Ressource, das verwendet wird, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau als ETag, aber in einigen Umgebungen 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 nicht mit einem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen) oder um zu verhindern, dass eine neue Ressource hochgeladen wird, 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 veraltet ist.

If-Unmodified-Since

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

Vary

Bestimmt, wie Anforderungsheader abgeglichen werden, um zu entscheiden, ob eine gecachte Antwort verwendet werden kann, anstatt 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.

Inhaltsverhandlung

Weitere Details finden Sie im Artikel zur Inhaltsverhandlung.

Accept

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

Accept-Encoding

Der Kodierungsalgorithmus, normalerweise ein Kompressionsalgorithmus, der auf die zurückgesendete Ressource angewendet werden kann.

Accept-Language

Informiert den Server über die menschliche Sprache, die der Server zurücksenden soll. Dies ist ein Hinweis und nicht unbedingt unter der vollständigen Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown) nicht zu überschreiben.

Accept-Patch

Ein Verhandlungsheader für Anfrageninhalt, der angibt, welchen Medientyp der Server in einer PATCH-Anfrage verstehen kann.

Accept-Post

Ein Verhandlungsheader für Anfrageninhalt, der angibt, welchen Medientyp der Server in einer POST-Anfrage verstehen kann.

Kontrollen

Expect

Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.

Max-Forwards

Gibt an, bei Nutzung von TRACE, wie viele Hops die Anfrage machen kann, bevor sie an den Absender zurückgegeben wird.

Cookies

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

Sendet Cookies vom Server an den User-Agent.

CORS

Für weitere Informationen lesen Sie die CORS-Dokumentation.

Access-Control-Allow-Credentials

Gibt an, ob die Antwort auf die Anfrage exponiert werden kann, wenn das Berechtigungsflag wahr ist.

Access-Control-Allow-Headers

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

Access-Control-Allow-Methods

Gibt an, welche Methoden bei der Zugriffsaufnahme auf die Ressource als Antwort auf eine Preflight-Anfrage erlaubt sind.

Access-Control-Allow-Origin

Zeigt an, ob die Antwort geteilt werden kann.

Access-Control-Expose-Headers

Gibt an, welche Header als Teil der Antwort exponiert werden können, indem ihre Namen aufgelistet werden.

Access-Control-Max-Age

Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage im Cache bleiben können.

Access-Control-Request-Headers

Wird bei der Ausgabe einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die tatsächliche Anfrage gemacht wird.

Access-Control-Request-Method

Wird bei der Ausgabe einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode bei der tatsächlichen Anfrage verwendet wird.

Origin

Gibt an, von wo ein Abruf stammt.

Timing-Allow-Origin

Gibt Ursprünge an, die die Werte der Attribute sehen dürfen, die über Funktionen der Ressourcentiming-API abgerufen werden, 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 präsentieren soll.

Integritätsdigests

Content-Digest Experimentell

Bietet einen Digest des Datenstroms von Oktetten, der in einer HTTP-Nachricht (dem Nachrichteninhalt) eingerahmt ist, abhängig von Content-Encoding und Content-Range.

Repr-Digest Experimentell

Bietet einen Digest der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zum Content-Digest berücksichtigt der Digest nicht Content-Encoding oder Content-Range.

Want-Content-Digest Experimentell

Gibt den Wunsch nach einem Content-Digest Header an. Es ist das Content- Analoge zu Want-Repr-Digest.

Want-Repr-Digest Experimentell

Gibt den Wunsch nach einem Repr-Digest Header an. Es ist das Repr- Analoge zu Want-Content-Digest.

Informationen zum Nachrichtenkörper

Content-Length

Die Größe der Ressource in Dezimalzahlen von Bytes.

Content-Type

Gibt den Medientyp der Ressource an.

Content-Encoding

Wird verwendet, um den Kompressionsalgorithmus zu spezifizieren.

Content-Language

Beschreibt die menschliche(n) Sprache(n), die für das Publikum bestimmt sind, sodass ein Benutzer basierend auf seinen eigenen bevorzugten Spracheinstellungen unterscheiden kann.

Content-Location

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

Präferenzen

Präferenzen können von Clients in Anfragen gesendet werden, um optionale Verhaltensweisen für Anfragen und Antworten anzuzeigen. Die Serverantwort kann angeben, ob eine Präferenz angewendet wurde, in Fällen, in denen sie für den Client sonst zweideutig wäre. Browser haben 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. Zum Beispiel kann es minimalen Antwortinhalt (return=minimal) oder asynchrone Verarbeitung (respond-async) anfordern. Der Server verarbeitet die Anfrage normal, wenn der Header nicht unterstützt wird.

Preference-Applied

Informiert den Client darüber, welche Präferenzen, die im Prefer-Header angegeben sind, vom Server angewendet wurden. Es ist ein reiner Antwortheader, der Transparenz über die Präferenzbehandlung bietet.

Proxies

Forwarded

Enthält Informationen von der clientseitigen Proxy-Server-Seite, die verändert oder verloren gehen, wenn ein Proxy auf dem Weg der Anfrage beteiligt ist.

Via

Wird von Proxies hinzugefügt, sowohl bei Forward- als auch bei Reverse-Proxies, und kann in den Anforderungs- und den Antwortheadern erscheinen.

Bereichsanforderungen

HTTP-Bereichsanforderungen erlauben es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanforderungen sind nützlich für Anwendungen wie Mediaplayer, die zufälligen Zugriff unterstützen, Datentools, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Download-Manager, die es dem Benutzer ermöglichen, einen Download zu pausieren und fortzusetzen.

Accept-Ranges

Gibt an, ob der Server Bereichsanforderungen unterstützt und, wenn 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 von zwei Bereichen von inkompatiblen Versionen der Ressource zu verhindern.

Content-Range

Gibt an, wo in einer vollständigen Nachricht ein Teil der Nachricht hingehört.

Weiterleitungen

Location

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

Refresh

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

Anforderungskontext

From

Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden User-Agent steuert.

Host

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

Referer

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

Referrer-Policy

Bestimmt, welche Referrer-Informationen im Referer-Header mit Anfragen enthalten sein sollen.

User-Agent

Enthält eine charakteristische Zeichenfolge, die es den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Software-Verkäufer oder die Softwareversion des anfordernden User-Agents zu identifizieren.

Antwortkontext

Allow

Listet die HTTP-Anfragemethoden auf, die von einer Ressource unterstützt werden.

Server

Enthält Informationen über die Software, die vom Ursprungsserver verwendet wird, um die Anfrage zu bearbeiten.

Sicherheit

Cross-Origin-Embedder-Policy (COEP)

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

Cross-Origin-Opener-Policy (COOP)

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

Cross-Origin-Resource-Policy (CORP)

Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch CORP-Erklärungsartikel.

Content-Security-Policy (CSP)

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

Content-Security-Policy-Report-Only

Ermöglicht Webentwicklern, Richtlinien zu testen, indem sie ihre Auswirkungen überwachen, aber nicht durchsetzen. Diese Verletzungsberichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.

Expect-CT Veraltet

Ermöglicht es Websites, sich für die Berichterstattung und Durchsetzung der Certificate Transparency zu entscheiden, um die Verwendung missbräuchlich ausgestellter Zertifikate für diese Website zu erkennen.

Permissions-Policy

Bietet einen Mechanismus, um die Verwendung von Browser-Features innerhalb des eigenen Rahmens einer Website zu erlauben oder zu verweigern und in <iframe>s, die sie einbettet.

Reporting-Endpoints Experimentell

Antwort-Header, der es Website-Besitzern ermöglicht, ein oder mehrere Endpunkte anzugeben, die zum Empfangen von Fehlern wie CSP-Verletzungsberichten, Cross-Origin-Opener-Policy-Berichten oder anderen generischen Verletzungen verwendet werden.

Strict-Transport-Security (HSTS)

Erzwingt die Kommunikation über HTTPS anstelle von 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 dass er die upgrade-insecure-requests-Direktive erfolgreich handhaben kann.

X-Content-Type-Options

Deaktiviert MIME-Sniffing und erzwingt, dass Browser den im Content-Type angegebenen Typ 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 domänenübergreifend zu verarbeiten, die andernfalls aufgrund der Same-Origin Policy eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients unerwünschte Anfragen blockieren.

X-Powered-By

Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, während sie keine nützlichen Informationen für die Anwendung oder ihre Besucher bieten. Entfernen Sie diesen Header, um potenzielle Schwachstellen nicht preiszugeben.

X-XSS-Protection

Aktiviert Filter zur Verhinderung von Cross-Site-Scripting (XSS).

Fetch-Metadaten-Anforderungsheader

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

Sec-Fetch-Site

Gibt die Beziehung zwischen dem Ursprungsort des Anforderungsinitiators und dem Zielort 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 den Modus der Anfrage an einen Server 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 Benutzeraktivierung ausgelöst wurde oder nicht. Es handelt sich um einen strukturierten Header, dessen Wert ein Boolean ist, sodass mögliche Werte ?0 für falsch und ?1 für wahr sind.

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 Anforderungsheader sind strenggenommen keine "Fetch-Metadaten-Anforderungsheader", liefern jedoch ähnlich Informationen darüber, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Cache-Verhalten zu ändern oder die Informationen, die zurückgegeben werden:

Sec-Purpose

Gibt den Zweck der Anfrage an, wenn der Zweck ein anderer als die unmittelbare Verwendung durch den User-Agent ist. Der Header hat derzeit einen möglichen Wert, prefetch, der angibt, dass die Ressource vorab zur möglichen späteren Navigation abgerufen wird.

Service-Worker-Navigation-Preload

Ein Anforderungsheader, der in vorweggenommenen Anfragen zum Abrufen einer Ressource während des Service-Worker-Starts gesendet wird. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einem Server mitzuteilen, dass eine andere Ressource zurückgegeben werden sollte als bei einer normalen fetch()-Operation.

Server gesendete Ereignisse

Reporting-Endpoints

Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser Warnungen und Fehlermeldungen senden soll, wenn er die Reporting-API verwendet.

Report-To Veraltet Nicht standardisiert

Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser Warnungen und Fehlermeldungen senden soll, wenn er die Reporting-API verwendet.

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, zusätzliche Felder am Ende einer chunked-Nachricht einzufügen.

WebSockets

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

Sec-WebSocket-Accept

Antwort-Header, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung zu aktualisieren.

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

Anforderungs-Header, der einen Schlüssel enthält, der bestätigt, dass der Client explizit 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 Möglichkeiten aufzulisten, um diesen Dienst zu erreichen.

Alt-Used

Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.

Date

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

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

Retry-After

Gibt an, wie lange der User-Agent warten soll, bevor er eine Folgeanforderung macht.

Server-Timing

Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.

Service-Worker

Wird in Abrufen für das Skriptressourc des Service Workers eingeschlossen. Dieser Header hilft Administratoren, Anfragen zu Service Worker-Skripten für Überwachungszwecke zu protokollieren.

Service-Worker-Allowed

Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header [in der Antwort des Service Worker-Skriptdes] beantwortet wird, [https://w3c.github.io/ServiceWorker/#service-worker-script-response].

SourceMap

Verlinkt zu einer Quellkarte, damit Debugger durch den ursprünglichen Quellcode schrittweise gehen können, anstatt durch generierten oder transformierten Code.

Upgrade

Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits bestehende Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Zum Beispiel kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- oder HTTPS-Verbindung in ein WebSocket zu aktualisieren.

Priority

Gibt einen Hinweis auf die Priorität eines bestimmten Ressourcenanforderung auf einer bestimmten Verbindung. Der Wert kann in einer Anforderung gesendet werden, um die Client-Priorität anzugeben, oder in einer Antwort, wenn der Server beschließt, die Anforderung neu zu priorisieren.

Experimentelle Header

Attributionsbericht-Header

Die Attribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen – zum Beispiel, wenn ein Benutzer auf eine auf einer Website eingebettete Anzeige klickt und dann den Artikel auf der Website eines Anbieters kauft – und dann Berichte über diese Konversionen zu erhalten. Sie tut dies ohne auf Drittanbieter-Tracking-Cookies zu vertrauen, sondern verlässt sich auf verschiedene Header, um Quellen und Auslöser zu registrieren, die zu einer Konversion verknüpft werden.

Attribution-Reporting-Eligible

Wird verwendet, um anzugeben, dass die Antwort, die der aktuellen Anfrage entspricht, berechtigt ist, an der Attributionsberichterstattung teilzunehmen, indem sie entweder eine Attributionsquelle oder einen Auslöser registriert.

Attribution-Reporting-Register-Source

Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, eingeschlossen, um eine Attributionsquelle zu registrieren.

Attribution-Reporting-Register-Trigger

Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, eingeschlossen, um einen Attributionsauslöser zu registrieren.

Client-Hinweise

HTTP-Client-Hinweise sind eine Reihe von Anforderungsheadern, die nützliche Informationen über den Client wie Gerätetyp und Netzwerkbedingungen bereitstellen und es Servern ermöglichen, das angebotene Material für diese Bedingungen zu optimieren.

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

Accept-CH

Server können Unterstützung für Client-Hinweise mithilfe des Accept-CH-Headerfeldes oder eines gleichwertigen HTML-<meta>-Elements mit dem http-equiv Attribut anzeigen.

Critical-CH Experimentell

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

Die verschiedenen Kategorien von Client-Hinweisen sind unten aufgelistet.

User-Agent-Client-Hinweise

Die UA-Client-Hinweise sind Anforderungsheader, die Informationen über den User-Agent, die Plattform/Architektur, auf der er läuft, sowie Benutzereinstellungen, die auf dem User-Agent oder der Plattform festgelegt sind, bereitstellen:

Sec-CH-UA Experimentell

Branding und Version des User-Agents.

Sec-CH-UA-Arch Experimentell

Plattformarchitektur des User-Agents.

Sec-CH-UA-Bitness Experimentell

CPU-Architektur-Bitness des User-Agents (zum Beispiel "64" Bit).

Sec-CH-UA-Form-Factors Experimentell

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

Sec-CH-UA-Full-Version Veraltet

Komplette Versionszeichenfolge des User-Agents.

Sec-CH-UA-Full-Version-List Experimentell

Volle Version für jede Marke in der Markenliste des User-Agents.

Sec-CH-UA-Mobile Experimentell

Der User-Agent läuft auf einem mobilen Gerät oder zieht allgemein eine "mobile" Benutzeroberfläche vor.

Sec-CH-UA-Model Experimentell

Gerätemodell des User-Agents.

Sec-CH-UA-Platform Experimentell

Betriebssystem/Plattform des User-Agents.

Sec-CH-UA-Platform-Version Experimentell

Betriebssystemversion des User-Agents.

Sec-CH-UA-WoW64 Experimentell

Gibt an, ob das User-Agent-Binärprogramms im 32-Bit-Modus auf 64-Bit-Windows läuft oder nicht.

Sec-CH-Prefers-Color-Scheme Experimentell

Benutzerpräferenz von dunklem oder hellem Farbmodus.

Sec-CH-Prefers-Reduced-Motion Experimentell

Benutzerpräferenz, weniger Animationen und Inhaltslayouts zu sehen.

Sec-CH-Prefers-Reduced-Transparency Experimentell

Anforderungsheader, der die Präferenz des User-Agents für reduzierte Transparenz angibt.

Hinweis: User-Agent-Client-Hinweise sind innerhalb von abgegrenzten Frames nicht verfügbar, da sie auf Berechtigungsrichtlinien-Delegation angewiesen sind, die verwendet werden könnten, um Daten zu leaken.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert

Antwort-Header, der verwendet wird, um das Bildgerät-Pixel-Verhältnis (DPR) bei Anfragen zu bestätigen, bei denen der Bildschirm-DPR-Client-Hinweis verwendet wurde, um eine Bildressource auszuwählen.

Device-Memory

Ungefähre Menge des verfügbaren RAM-Speicher beim Client. Dies ist Teil der Device Memory API.

DPR Veraltet Nicht standardisiert

Anforderungs-Header, der das Pixelverhältnis des Clientgeräts liefert (die Anzahl physischer Gerätepixel für jedes CSS-Pixel).

Viewport-Width Veraltet Nicht standardisiert

Anforderungs-Header, der die Layoutansichtsbreite des Clients in CSS-Pixeln bereitstellt.

Width Veraltet Nicht standardisiert

Anforderungs-Header, der die gewünschte Ressourcenbreite in physischen Pixeln angibt (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hinweise

Netzwerk-Client-Hhinweise ermöglichen es einem Server, zu entscheiden, welche Informationen basierend auf der Benutzerwahl sowie der Netzwerkbandbreite und -verzögerung gesendet werden.

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

ECT Experimentell

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

RTT Experimentell

Round Trip Time (RTT) der Anwendungsebene in Millisekunden, die die Serververarbeitungszeit umfasst. Dies ist Teil der Network Information API.

Save-Data Experimentell

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

Transport von Kompressionswörterbüchern

Transport von Kompressionswörterbüchern ist eine Methode, ein gemeinsames Kompressionswörterbuch zu verwenden, um die Transportgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch in Brotli-Kompression oder Zstandard-Kompression zu nutzen.

Available-Dictionary Experimentell

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

Dictionary-ID Experimentell

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

Use-As-Dictionary Experimentell

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

Privatsphäre

DNT Veraltet Nicht standardisiert

Anforderungs-Header, der die Verarbeitungseinstellungen des Benutzers (Do Not Track / Nicht Verfolgen) angibt. Veraltet zugunsten des Global Privacy Control (GPC), das Server unter Verwendung des Sec-GPC-Headers kommuniziert und für Clients über navigator.globalPrivacyControl zugänglich ist.

Tk Veraltet Nicht standardisiert

Antwort-Header, der den Tracking-Status angibt, der auf die entsprechende Anfrage angewendet wurde. Wird zusammen mit DNT verwendet.

Sec-GPC Nicht standardisiert Experimentell

Gibt an, ob der Benutzer einer Website oder einem Dienst erlaubt, ihre persönlichen Informationen mit Dritten zu verkaufen oder zu teilen.

Sicherheit

Origin-Agent-Cluster Experimentell

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

Server gesendete Ereignisse

NEL Experimentell

Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Richtlinie zur Berichterstattung von Netzwerkausfällen zu deklarieren.

Themen-API

Die Themen-API bietet einen Mechanismus für Entwickler, um Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. Weitere Informationen finden Sie in der Dokumentation zur Themen-API.

Observe-Browsing-Topics Experimentell Nicht standardisiert

Antwort-Header, der verwendet wird, um Themen von Interesse zu kennzeichnen, die aus der URL einer aufgerufenen Website abgeleitet wurden, die in der Antwort auf eine Anfrage zu einer Funktion verwendet wurde, die die Themen-API aktiviert](/de/docs/Web/API/Topics_API/Using#what_api_features_enable_the_topics_api).

Sec-Browsing-Topics Experimentell Nicht standardisiert

Anforderungs-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Werbetechnologieplattform verwendet wird, um eine personalisierte Anzeige auszuwählen.

Sonstiges

Accept-Signature Experimentell

Ein Client kann das Accept-Signature-Headerfeld senden, um die Absicht anzugeben, die sich bietenden Signaturen zu nutzen und anzugeben, welche Arten von Signaturen es unterstützt.

Early-Data Experimentell

Gibt an, dass die Anfrage in TLS-Frühdaten übertragen wurde.

Set-Login Experimentell

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

Signature Experimentell

Das Signature-Headerfeld enthält eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität dieser Signatur bestimmt und aktualisiert werden kann.

Signed-Headers Experimentell

Das Signed-Headers-Headerfeld identifiziert eine geordnete Liste von Antwortheaderfeldern, die in einer Signatur enthalten sein sollen.

Speculation-Rules Experimentell

Bietet eine Liste von URLs, die auf Textressourcen verweisen, die Spekulationsregel-JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregel-Set des Dokuments hinzugefügt.

Sec-Speculation-Tags Experimentell

Enthält einen oder mehrere Stichwörter aus den Spekulationsregeln, die zur Spekulation geführt haben, sodass ein Server identifizieren kann, welche Regeln eine Spekulation verursacht haben und sie möglicherweise blockieren kann.

Supports-Loading-Mode Experimentell

Wird von einem Navigationsziel gesetzt, um die Verwendung verschiedener riskanterer Lademodi zu unterstützen. Zum Beispiel erfordert das Prerendern von cross-origin, same-site prerendering einen Supports-Loading-Mode-Wert von credentialed-prerender.

Nicht standardisierte Header

X-Forwarded-For Nicht standardisiert

Identifiziert die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder einen Lastverteiler mit einem Webserver verbindet.

X-Forwarded-Host Nicht standardisiert

Identifiziert den ursprünglichen Host, mit dem der Client eine Verbindung zu Ihrem Proxy oder Lastverteiler hergestellt hat.

X-Forwarded-Proto Nicht standardisiert

Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client beim Verbinden zu Ihrem Proxy oder Lastverteiler verwendet hat.

X-DNS-Prefetch-Control Nicht standardisiert

Kontrolliert DNS-Prefetching, eine Funktion, durch die Browser vorab Domainnamenauflösungen sowohl auf Links, die der Benutzer möglicherweise auswählt, als auch URLs für Artikel, die vom Dokument referenziert werden, einschließlich Bilder, CSS, JavaScript und so weiter, durchführen.

X-Robots-Tag Nicht standardisiert

Der X-Robots-Tag-HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb der öffentlichen Suchmaschinenergebnisse indexiert werden soll. Der Header entspricht effektiv dem <meta name="robots" content="…">.

Veraltete Header

Pragma Veraltet

Implementierungsspezifischer Header, der entlang der gesamten Anforderungs-Antwort-Kette unterschiedliche Auswirkungen haben kann. Wird für die Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, wo der Cache-Control-Header noch nicht vorhanden ist.

Warning Veraltet

Generelle Warninformationen über mögliche Probleme.

Siehe auch