HTTP-Header

WWW-Authenticate

Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden soll.

Authorization

Enthält die Anmeldeinformationen, um einen User-Agent beim Server zu authentifizieren.

Proxy-Authenticate

Definiert die Authentifizierungsmethode, die hinter einem Proxy-Server verwendet werden soll.

Proxy-Authorization

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

Age

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

Cache-Control

Direktiven für Zwischenspeichermechanismen in Anfragen und Antworten.

Clear-Site-Data

Löscht Browsing-Daten (z. B. Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind.

Expires

Das Datum/die Uhrzeit, nach der die Antwort als veraltet betrachtet wird.

No-Vary-Search Experimentell

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

Last-Modified

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

ETag

Eine eindeutige Zeichenkette, 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 (für sichere 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 dann ü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 dann übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies stellt die Kohärenz eines neuen Fragments eines spezifischen Bereichs mit vorherigen sicher oder implementiert ein optimistisches Mehrbenutzer-Kontrollsystem beim Ändern bestehender Dokumente.

Vary

Bestimmt, wie Anforderungs-Header abgeglichen werden sollen, um zu entscheiden, ob eine gecachte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.

Connection

Steuert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion offen bleibt.

Keep-Alive

Steuert, wie lange eine persistente Verbindung offen bleiben soll.

Für weitere Details, siehe den Artikel Inhaltsverhandlung.

Accept

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

Accept-Encoding

Der Kodierungsalgorithmus, normalerweise ein Komprimierungsalgorithmus, 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 vollständig unter der Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerwahl (wie das Auswählen einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.

Accept-Patch

Ein Antwort-Header zur Anforderungsinhaltsverhandlung, der angibt, welchen Medientyp der Server in einer PATCH-Anforderung verstehen kann.

Accept-Post

Ein Antwort-Header zur Anforderungsinhaltsverhandlung, der angibt, welchen Medientyp der Server in einer POST-Anforderung verstehen kann.

Expect

Gibt Erwartungen an, die der Server erfüllen muss, um die Anfrage ordnungsgemäß zu bearbeiten.

Max-Forwards

Bei Verwendung von TRACE, gibt die maximale Anzahl an Hops an, die die Anfrage machen kann, bevor sie dem Absender zurückgegeben wird.

Cookie

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

Set-Cookie

Sendet Cookies vom Server an den User-Agent.

Für weitere Informationen siehe die CORS-Dokumentation.

Access-Control-Allow-Credentials

Gibt an, ob die Antwort auf die Anfrage bereitgestellt werden kann, wenn das Anmeldeinformations-Flag auf true gesetzt ist.

Access-Control-Allow-Headers

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

Access-Control-Allow-Methods

Gibt die Methoden an, die beim Zugriff auf die Ressource in der Antwort auf eine Preflight-Anfrage erlaubt sind.

Access-Control-Allow-Origin

Gibt an, ob die Antwort geteilt werden kann.

Access-Control-Expose-Headers

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

Access-Control-Max-Age

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

Access-Control-Request-Headers

Wird bei einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.

Access-Control-Request-Method

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

Origin

Gibt an, von wo eine Anfrage stammt.

Timing-Allow-Origin

Gibt Ursprünge an, die die Werte von Attributen sehen dürfen, die über Funktionen der Resource Timing API abgerufen werden, die ansonsten aufgrund von Cross-Origin-Einschränkungen als null gemeldet würden.

Content-Disposition

Gibt an, ob die übertragene Ressource inline angezeigt werden soll (Standardverhalten ohne Header) oder ob sie als Download behandelt werden soll und der Browser einen "Speichern unter"-Dialog präsentieren soll.

Content-Digest Experimentell

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

Repr-Digest Experimentell

Bietet einen Digest der ausgewählten Repräsentation der Zielressource vor der Übertragung. Im Gegensatz zum Content-Digest berücksichtigt der Digest weder Content-Encoding noch Content-Range.

Want-Content-Digest Experimentell

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

Want-Repr-Digest Experimentell

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

Content-Length

Die Größe der Ressource in dezimaler Anzahl von Bytes.

Content-Type

Weist den Medientyp der Ressource an.

Content-Encoding

Wird verwendet, um den Komprimierungsalgorithmus anzugeben.

Content-Language

Beschreibt die menschliche Sprache(n), für die der Inhalt bestimmt ist, sodass ein Benutzer nach der eigenen bevorzugten Sprache differenzieren kann.

Content-Location

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

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, in Fällen, in denen es ansonsten für den Client nicht eindeutig wäre. Browser haben keine native Handhabung zum Senden von Präferenzen über diese Header; sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.

Prefer

Gibt Präferenzen für spezifische Serververhalten während der Anfragenverarbeitung an. Beispielsweise 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 Antwort-Header, der Transparenz über die Präferenzhandhabung bietet.

Forwarded

Enthält Informationen von der dem Client zugewandten Seite von Proxy-Servern, die geändert oder verloren gehen, wenn ein Proxy auf dem Pfad der Anfrage beteiligt ist.

Via

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

HTTP Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen 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 dem Benutzer das Pausieren 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 das angegebene ETag oder das Datum der Remote-Ressource übereinstimmt. Wird verwendet, um zu verhindern, dass zwei Bereiche von einer inkompatiblen Version der Ressource heruntergeladen werden.

Content-Range

Gibt an, wo sich in einer vollständigen Nachricht ein Teilnachricht befindet.

Location

Gibt die URL an, auf die eine Seite umgeleitet werden soll.

Refresh

Fordert den Browser auf, die Seite neu zu laden oder zu einer anderen umzuleiten. Nimmt denselben Wert wie das meta Element mit http-equiv="refresh".

From

Enthält eine Internet-E-Mail-Adresse eines menschlichen Benutzers, der die anfordernde Benutzeragentur kontrolliert.

Host

Gibt den Domainnamen des Servers (für das virtuelle 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 verfolgt wurde.

Referrer-Policy

Bestimmt, welche Referrer-Informationen im Referer Header bei Anfragen enthalten sein sollten.

User-Agent

Enthält eine charakteristische Zeichenkette, die den Netzwerkprotokollpartnern ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion der anfordernden Software-Benutzeragentur zu identifizieren.

Allow

Listet die Menge der HTTP-Anforderungsmethoden 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.

Cross-Origin-Embedder-Policy (COEP)

Ermöglicht einem Server, eine Embedding-Policy für ein bestimmtes Dokument festzulegen.

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 den CORP-Erklärartikel.

Content-Security-Policy (CSP)

Kontrolliert Ressourcen, die der Benutzeragent für eine bestimmte Seite laden darf.

Content-Security-Policy-Report-Only

Erlaubt Webentwicklern, Policies zu testen, indem sie ihre Effekte überwachen, aber nicht durchsetzen. Diese Verstoßberichte 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 Meldung und Durchsetzung der Certificate Transparency zu entscheiden, um die Verwendung von falsch ausgestellten Zertifikaten für diese Site zu erkennen.

Permissions-Policy

Bietet einen Mechanismus zum Erlauben und Verweigern der Verwendung von Browserfunktionen im eigenen Frame einer Website und in <iframe>s, die es einbettet.

Reporting-Endpoints Experimentell

Antwort-Header, der Website-Besitzern erlaubt, ein oder mehrere Endpunkte anzugeben, die verwendet werden, um Fehler wie CSP-Verstoßberichte, Cross-Origin-Opener-Policy-Berichte oder andere allgemeine Verstöße zu empfangen.

Strict-Transport-Security (HSTS)

Erzwingt die Kommunikation über HTTPS statt 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 das MIME-Sniffing und zwingt den Browser, den im Content-Type angegebenen Typ zu verwenden.

X-Frame-Options (XFO)

Gibt an, ob ein Browser erlauben soll, eine Seite in einem <frame>, <iframe>, <embed> oder <object> darzustellen.

X-Permitted-Cross-Domain-Policies

Eine Cross-Domain-Policy-Datei kann Clients, wie Adobe Acrobat oder Apache Flex (unter anderen), die Berechtigung erteilen, Daten über Domänen hinweg zu handhaben, die ansonsten aufgrund der Ssame-Origin-Policy eingeschränkt würden. Der X-Permitted-Cross-Domain-Policies Header ü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, während sie der Anwendung oder ihren Besuchern keinen Nutzen bieten. Entfernen Sie diesen Header, um potenzielle Schwachstellen nicht offenzulegen.

X-XSS-Protection

Aktiviert die Filterung von Cross-Site-Scripting.

Fetch-Metadaten-Anforderungs-Header bieten Informationen über den Kontext, aus dem die Anfrage stammt. Ein Server kann sie verwenden, um zu entscheiden, ob eine Anfrage auf Basis ihres Ursprungs und wie die Ressource verwendet wird, erlaubt werden soll.

Sec-Fetch-Site

Gibt die Beziehung zwischen dem Ursprung des Anforderungsinitiators und dem Zielursprung an. Es handelt sich um einen Structured Header, dessen Wert ein Token mit 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 Structured Header, dessen Wert ein Token mit 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 oder nicht. Es handelt sich um einen Structured Header, dessen Wert ein Boolean ist, so dass die möglichen Werte ?0 für false und ?1 für true sind.

Sec-Fetch-Dest

Gibt das Ziel der Anfrage an. Es handelt sich um einen Structured Header, dessen Wert ein Token mit 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 Anforderungs-Header sind nicht strikt "Fetch-Metadaten-Anforderungs-Header", bieten jedoch ähnliche Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Cache-Verhalten zu ändern oder die zurückgegebenen Informationen anzupassen:

Sec-Purpose

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

Service-Worker-Navigation-Preload

Ein Anforderungs-Header, der in vorauseilender Anfrage gesendet wird, um eine Ressource während des Service-Worker-Boot-Vorgangs mit fetch() abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() festgelegt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource zurückgegeben werden sollte als in einer normalen fetch()-Operation.

Reporting-Endpoints

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

Report-To Veraltet Nicht standardisiert

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

Transfer-Encoding

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

TE

Gibt die Transfer-Codierungen an, die der User-Agent akzeptieren möchte.

Trailer

Ermöglicht es dem Absender, zusätzliche Felder am Ende der gechunkten Nachricht einzuschließen.

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

Sec-WebSocket-Accept

Antwort-Header, der anzeigt, dass der Server bereit ist, zu einer WebSocket-Verbindung zu wechseln.

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 überprüft, dass der Client explizit beabsichtigt, eine WebSocket zu öffnen.

Sec-WebSocket-Protocol

In Anfragen gibt dieser Header die vom Client unterstützten Sub-Protokolle in bevorzugter Reihenfolge an. In Antworten gibt er das vom Server aus den Präferenzen des Clients ausgewählte Sub-Protokoll 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 nicht vom Server unterstützt wird, und listet die Versionen auf, die der Server unterstützt.

Alt-Svc

Wird verwendet, um alternative Möglichkeiten aufzulisten, diesen Dienst zu erreichen.

Alt-Used

Wird verwendet, um den alternativen Dienst zu identifizieren, der verwendet wird.

Date

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

Link

Dieses Entity-Header-Feld bietet eine Möglichkeit für die Serialisierung eines oder mehrerer Links in HTTP-Head-ern. Es ist semantisch äquivalent zum HTML <link> Element.

Retry-After

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

Server-Timing

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

Service-Worker

Wird in Abfragen nach einem Service-Worker-Skriptressource enthalten. Dieser Header hilft Administratoren dabei, Anfragen zu Service-Worker-Skripts zu protokollieren, um Überwachungszwecke zu erfüllen.

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, damit Debugger durch den Original-Quellcode anstelle von generiertem oder transformiertem Code navigieren können.

Upgrade

Dieser nur für HTTP/1.1 gültige Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Beispielsweise kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 zu aktualisieren oder eine HTTP- oder HTTPS-Verbindung in eine WebSocket zu ändern.

Priority

Bietet einen Hinweis auf die Priorität einer bestimmten Ressourcenanforderung 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 entscheidet, die Anfrage neu zu priorisieren.

Die Attribution Reporting API ermöglicht es Entwicklern, Conversions zu messen — beispielsweise wenn ein Benutzer auf eine Anzeige klickt, die auf einer Website eingebettet ist, und dann das Produkt auf der Seite des Anbieters kauft — und dann Berichte über diese Conversions zu erstellen. Dies erfolgt ohne die Verwendung von Drittanbieter-Tracking-Cookies, sondern durch verschiedene Header, um Quellen und Auslöser zu registrieren, die zusammenpassen, um eine Conversion anzuzeigen.

Attribution-Reporting-Eligible

Wird verwendet, um anzuzeigen, dass die Antwort auf die aktuelle Anfrage berechtigt ist, an der Attribution-Meldung teilzunehmen, indem entweder eine Attributionsquelle oder ein Auslöser registriert wird.

Attribution-Reporting-Register-Source

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

Attribution-Reporting-Register-Trigger

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

HTTP Client-Hinweise sind ein Satz von Anforderungs-Headern, die nützliche Informationen über den Client wie den Gerätetyp und die Netzwerkbedingungen bereitstellen und es Servern ermöglichen, die bereitgestellten Inhalte für diese Bedingungen zu optimieren.

Server fordern proaktiv die Client-Hinweis-Header an, die sie vom Client benötigen, indem sie Accept-CH verwenden. Der Client kann dann entscheiden, die angeforderten Header in nachfolgenden Anfragen einzuschließen.

Accept-CH

Server können Unterstützung für Client-Hinweise über das Accept-CH Header-Feld oder ein gleichwertiges HTML <meta> Element mit dem http-equiv Attribut anzeigen.

Critical-CH Experimentell

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

Die verschiedenen Kategorien von Client-Hinweisen sind unten aufgeführt.

User-Agent-Client-Hinweise

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

Sec-CH-UA Experimentell

User-Agent-Branding und -Version.

Sec-CH-UA-Arch Experimentell

User-Agent-unterliegende Plattformarchitektur.

Sec-CH-UA-Bitness Experimentell

Bitness der User-Agent-unterliegenden CPU-Architektur (zum Beispiel "64" Bit).

Sec-CH-UA-Form-Factors Experimentell

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

Sec-CH-UA-Full-Version Veraltet

Vollständige Versionszeichenkette des User-Agents.

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

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

Sec-CH-UA-Mobile Experimentell

User-Agent läuft auf einem mobilen Gerät oder bevorzugt allgemein ein "mobiles" Benutzererlebnis.

Sec-CH-UA-Model Experimentell

Gerätemodell des User-Agents.

Sec-CH-UA-Platform Experimentell

Unterliegendes Betriebssystem/Plattform des User-Agents.

Sec-CH-UA-Platform-Version Experimentell

Unterliegende Betriebssystemversion des User-Agents.

Sec-CH-UA-WoW64 Experimentell

Gibt an, ob das User-Agent-Programm im 32-Bit-Modus auf 64-Bit-Windows läuft.

Sec-CH-Prefers-Color-Scheme Experimentell

Bevorzugung des Benutzers für ein dunkles oder helles Farbschema.

Sec-CH-Prefers-Reduced-Motion Experimentell

Bevorzugung des Benutzers, weniger Animationen und Inhaltsverschiebungen zu sehen.

Sec-CH-Prefers-Reduced-Transparency Experimentell

Anfrage-Header, der die Bevorzugung des Benutzers für reduzierte Transparenz angibt.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert

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

Device-Memory

Ungefähre Menge an verfügbarem RAM-Speicher des Clients. Dies ist Teil der Gerätespeicher-API.

DPR Veraltet Nicht standardisiert

Anforderungs-Header, der das Verhältnis von Gerät zu Pixel des Clients angibt (die Anzahl der physischen Gerätepixel für jedes CSS-Pixel).

Viewport-Width Veraltet Nicht standardisiert

Anforderungs-Header gibt die Layout-Viewport-Breite des Clients in CSS-Pixeln an.

Width Veraltet Nicht standardisiert

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

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise ermöglichen es einem Server zu entscheiden, welche Informationen basierend auf der Nutzerwahl und Netwerkbandbreite und -verzögerung gesendet werden.

Downlink Experimentell

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

ECT Experimentell

Der Effektive Verbindungstyp ("Netzwerkprofil"), der am besten zu Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Netzwerkinformationen-API.

RTT Experimentell

Anwendungsbezogene Rundlaufzeit (RTT) in Millisekunden, die die Serververarbeitungszeit einschließt. Dies ist Teil der Netzwerkinformationen-API.

Save-Data Experimentell

Ein String on, das die Präferenz der Benutzerausrüstung für reduzierte Datennutzung angibt.

Kompressionswörterbuch-Transport ist eine Möglichkeit, ein gemeinsam genutztes Kompressionswörterbuch zu verwenden, um die Transportgröße von HTTP-Antworten zu reduzieren, anstatt das Standard-Static-Wörterbuch in Brotli-Kompression oder Zstandard-Kompression zu verwenden.

Available-Dictionary Experimentell

Ein Browser kann diesen Anforderungs-Header verwenden, um das beste Wörterbuch, das ihm zur Verfügung steht, anzugeben, damit der Server es 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 nach 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 passenden Kriterien auf, für die das Wörterbuch in zukünftigen Anfragen verwendet werden kann.

DNT Veraltet Nicht standardisiert

Anforderungs-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Veraltet zu Gunsten von Global Privacy Control (GPC), die den Servern über den Sec-GPC Header mitgeteilt wird und auf Client-Seite ü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 in Verbindung mit DNT verwendet.

Sec-GPC Nicht standardisiert Experimentell

Gibt an, ob der Benutzer zustimmt, dass eine Website oder ein Dienst seine persönlichen Informationen an Dritte verkaufen oder weitergeben kann.

Origin-Agent-Cluster Experimentell

Antwort-Header, der verwendet wird, um anzugeben, dass das zugehörige Document in einen ursprungsbezogenen Agent-Cluster platziert werden sollte. Diese Isolierung ermöglicht es User-Agents, Implementierungs-spezifische Ressourcen für Agent-Cluster, wie Prozesse oder Threads, effizienter zuzuweisen.

NEL Experimentell

Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Richtlinie zur Netzwerkausfallmeldung zu erklären.

Die Topics-API bietet einen Mechanismus, mit dem Entwickler Anwendungsfälle wie interessenbasierte Werbung (IBA) implementieren können. Siehe die Topics-API-Dokumentation für weitere Informationen.

Observe-Browsing-Topics Experimentell Nicht standardisiert

Antwort-Header, der verwendet wird, um Interessenbeobachtungen, die aus der URL einer aufrufenden Website abgeleitet wurden, als beobachtet zu kennzeichnen, wenn die Antwort auf eine Anfrage generiert wird, die durch eine Funktion, die die Topics-API aktiviert.

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 Ad-Tech-Plattform verwendet wird, um eine personalisierte Werbung auszuwählen und anzuzeigen.

Accept-Signature Experimentell

Ein Client kann den Accept-Signature Header-Feld senden, um die Absicht anzugeben, verfügbaren Signaturen zu nutzen und anzugeben, welche Arten von Signaturen er unterstützt.

Early-Data Experimentell

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

Set-Login Experimentell

Antwort-Header, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, d.h. ob ein oder mehrere Benutzer beim IdP im aktuellen Browser angemeldet sind oder nicht. Dies wird vom Browser gespeichert und für die FedCM API verwendet.

Signature Experimentell

Der Signature Header-Feld überträgt eine Liste von Signaturen für ein Austauschdienst, jede begleitet von Informationen darüber, wie die Autorität dieser Signatur festgestellt und aktualisiert werden kann.

Signed-Headers Experimentell

Der Signed-Headers Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur einbezogen werden sollen.

Speculation-Rules Experimentell

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

Supports-Loading-Mode Experimentell

Wird von einem Navigationsziel gesetzt, um die Verwendung verschiedener höherer Risiko-Lademodi zu erlauben. Zum Beispiel erfordert die Cross-Origin, gleiche Site Vorladen einen Supports-Loading-Mode Wert von credentialed-prerender.

X-Forwarded-For Nicht standardisiert

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

X-Forwarded-Host Nicht standardisiert

Identifiziert den ursprünglichen Host, der vom Client verwendet wurde, um sich mit Ihrem Proxy oder Load-Balancer zu verbinden.

X-Forwarded-Proto Nicht standardisiert

Identifiziert das Protokoll (HTTP oder HTTPS), das der Client verwendet hat, um sich mit Ihrem Proxy oder Load-Balancer zu verbinden.

X-DNS-Prefetch-Control Nicht standardisiert

Steuert die DNS-Vorabrufung, eine Funktion, bei der Browser proaktiv die Domainnamenauflösung sowohl bei Links, die der Benutzer möglicherweise verfolgen könnte, als auch bei URLs für Elemente durchführen, auf die im Dokument verwiesen wird, einschließlich Bilder, CSS, JavaScript, usw.

X-Robots-Tag Nicht standardisiert

Der X-Robots-Tag HTTP-Header wird verwendet, um anzugeben, wie eine Webseite in den Ergebnissen öffentlicher Suchmaschinen indexiert werden soll. Der Header ist effektiv äquivalent zu <meta name="robots" content="…">.

Pragma Veraltet

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

Warning Veraltet

Allgemeine Warninformationen über mögliche Probleme.

• Wikipedia-Seite zur Liste der HTTP-Header
• IANA-Register
• HTTP-Arbeitsgruppe