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 auf Groß- und Kleinschreibung beachtender Name, gefolgt von einem Doppelpunkt, dann optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und darüber hinaus werden Header in Kleinbuchstaben angezeigt, wenn sie in Entwicklerwerkzeugen betrachtet werden (accept: */*), und mit einem Doppelpunkt für eine spezielle Gruppe von Pseudo-Headern versehen (:status: 200). 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 es verursachte, als nicht standardmäßige Felder in RFC 6648 standardisiert wurden, aufgegeben; andere sind im IANA HTTP Field Name Registry aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status.

Header können nach ihren Kontexten gruppiert werden:

Request-Header

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

Response-Header

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

Representation-Header

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

Payload-Header

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

Header können auch danach gruppiert werden, wie Proxies mit ihnen umgehen:

End-to-End-Header

Diese Header müssen an den Endempfänger der Nachricht übermittelt 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 Transportschichtverbindung von Bedeutung und dürfen nicht von Proxies weitergeleitet oder zwischengespeichert werden. Hinweis: Nur Hop-by-Hop-Header können mit dem Connection-Header festgelegt werden.

Authentifizierung

WWW-Authenticate

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

Authorization

Enthält die Anmeldedaten, um einen Benutzer-Agenten gegenüber 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 Benutzer-Agenten gegenüber einem Proxy-Server zu authentifizieren.

Caching

Age

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

Cache-Control

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

Clear-Site-Data

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

Expires

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

Gibt eine Reihe von Regeln an, die definieren, wie sich die Abfrageparameter einer URL auf die Cache-Abstimmung auswirken werden. Diese Regeln bestimmen, ob die gleiche URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden soll.

Konditionale Header

Last-Modified

Das Datum der letzten Änderung der Ressource, verwendet 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 Zeichenkette, 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 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 dann zu übertragen, wenn der Cache veraltet ist.

If-Unmodified-Since

Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies stellt die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorhergehenden sicher oder implementiert ein optimistisches Synchronisationskontrollsystem, wenn bestehende Dokumente geändert werden.

Vary

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

Verbindungsverwaltung

Connection

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

Keep-Alive

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

Inhaltsaushandlung

Für weitere Details lesen Sie den Artikel zur Inhaltsaushandlung.

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

Accept-Patch

Ein Request Content Negotiation-Antwort-Header, der angibt, welcher Medientyp der Server in einer PATCH-Anfrage verstehen kann.

Accept-Post

Ein Request Content Negotiation-Antwort-Header, der angibt, welcher Medientyp der Server in einer POST-Anfrage verstehen kann.

Steuerung

Expect

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

Max-Forwards

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

Cookies

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

Sendet Cookies vom Server an den Benutzer-Agenten.

CORS

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

Access-Control-Allow-Credentials

Gibt an, ob die Antwort auf die Anfrage offen gelegt werden kann, wenn das Anmeldeinformationen-Flag wahr ist.

Access-Control-Allow-Headers

Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzuzeigen, welche HTTP-Header bei der eigentlichen Anforderung verwendet werden dürfen.

Access-Control-Allow-Methods

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

Access-Control-Allow-Origin

Gibt an, ob die Antwort freigegeben werden kann.

Access-Control-Expose-Headers

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

Access-Control-Max-Age

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

Access-Control-Request-Headers

Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die eigentliche Anforderung gestellt wird.

Access-Control-Request-Method

Wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Methode bei der eigentlichen Anfrage verwendet wird.

Origin

Gibt an, woher ein Abruf stammt.

Timing-Allow-Origin

Gibt die Ursprünge an, die berechtigt sind, Werte von Attributen zu sehen, die über Funktionen der Resource Timing API abgerufen wurden, die sonst aufgrund von Cross-Origin-Beschrä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 sollte und der Browser einen "speichern unter" Dialog präsentieren soll.

Integritätsprüfsummen

Content-Digest Experimentell

Bietet eine Prüfsumme des Stroms von Oktetten, die in einer HTTP-Nachricht eingerahmt sind (den Nachrichteninhalt), abhängig von Content-Encoding und Content-Range.

Repr-Digest Experimentell

Bietet eine Prüfsumme der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zu Content-Digest berücksichtigt die Prüfsumme weder Content-Encoding noch 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.

Integritätspolitik

Integrity-Policy

Stellt sicher, dass alle Ressourcen, die vom Benutzer-Agenten geladen werden (einer bestimmten Art), Subresource Integrity-Garantien erfüllen.

Integrity-Policy-Report-Only

Berichtet über Ressourcen, die der Benutzer-Agent lädt, die Subresource Integrity-Garantien verletzen würden, wenn die Integritätspolitik durchgesetzt würde (mit dem Integrity-Policy-Header).

Nachrichtenkörperinformationen

Content-Length

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

Content-Type

Gibt den Medientyp der Ressource an.

Content-Encoding

Verwendet, um den Komprimierungsalgorithmus anzugeben.

Content-Language

Beschreibt die menschliche(n) Sprache(n), die für das Publikum bestimmt sind, sodass es einem Benutzer erlaubt, nach den eigenen bevorzugten Sprachen zu differenzieren.

Content-Location

Gibt einen alternativen Speicherort 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 wird, in Fällen, in denen es ansonsten für den Client zweideutig wäre. Browser verfügen über keine native Unterstützung, um Präferenzen über diese Header zu senden; sie werden in benutzerdefinierten, implementationsspezifischen Clients verwendet.

Prefer

Gibt Präferenzen für bestimmte Serververhalten während der Anfrageverarbeitung an. Beispielsweise kann es minimale Antwortinhalte (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 wurden, vom Server angewendet wurden. Es ist ein reiner Antwort-Header, der Transparenz über die Präferenzbehandlung bietet.

Proxies

Forwarded

Enthält Informationen von der Client-seitigen Seite von Proxy-Servern, die geändert oder verloren gehen, wenn ein Proxy im Anforderungspfad beteiligt ist.

Via

Wird von Proxies hinzugefügt, sowohl von Forward- als auch von Reverse-Proxies, und kann sowohl in den Anfrage-Headern als auch in den 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 Mediaplayer, die zufälligen Zugriff unterstützen, Datentools, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Downloadmanager, die dem Benutzer erlauben, einen Download zu pausieren und fortzusetzen.

Accept-Ranges

Zeigt an, ob der Server Bereichsanfragen 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 entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen aus inkompatiblen Versionen der Ressource zu verhindern.

Content-Range

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

Umleitungen

Location

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

Refresh

Weist den Browser an, die Seite neu zu laden oder zu einer anderen umzuleiten. Nimmt 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 Benutzer-Agenten kontrolliert.

Host

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

Referer

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

Referrer-Policy

Regelt, welche Referrerinformationen im Referer-Header mit Anfragen gesendet werden sollen.

User-Agent

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

Antwortkontext

Allow

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

Sicherheit

Cross-Origin-Embedder-Policy (COEP)

Ermöglicht einem Server, eine Einbettungsrichtlinie für ein gegebenes Dokument zu deklarieren.

Cross-Origin-Opener-Policy (COOP)

Verhindert, dass andere Domänen ein Fenster öffnen/kontrollieren.

Cross-Origin-Resource-Policy (CORP)

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

Content-Security-Policy (CSP)

Kontrolliert Ressourcen, die der Benutzer-Agent laden darf, für eine gegebene Seite.

Content-Security-Policy-Report-Only

Ermöglicht Webentwicklern, Richtlinien zu testen, indem ihre Auswirkungen überwacht, aber nicht durchgesetzt werden. Diese Verstöße-Berichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.

Expect-CT Veraltet

Ermöglicht es Websites, bei der Berichterstattung und Durchsetzung von Zertifikatstransparenz opt-in zu wählen, um die Verwendung von fehlerhaften Zertifikaten für diese Website zu erkennen.

Permissions-Policy

Bietet einen Mechanismus, um die Verwendung von Browserfunktionen in einem eigenen Rahmen einer Website und in <iframe>s, die sie einbettet, zu erlauben oder zu verbieten.

Reporting-Endpoints Experimentell

Antwort-Header, der es Website-Besitzern ermöglicht, einen oder mehrere Endpunkte anzugeben, die verwendet werden, um Fehler wie CSP-Verletzungsberichte, Cross-Origin-Opener-Policy-Berichte oder andere generische Verstöße zu erhalten.

Strict-Transport-Security (HSTS)

Erzwingt die Kommunikation über HTTPS anstelle von HTTP.

Upgrade-Insecure-Requests

Sendet ein Signal an den Server, dass der Client eine präferenzierte, verschlüsselte und authentifizierte Antwort wünscht und dass er erfolgreich die upgrade-insecure-requests-Direktive behandeln kann.

X-Content-Type-Options

Deaktiviert MIME-Sniffing und zwingt den Browser, den im Content-Type-Header 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 Crosse-Domain-Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderem) die Berechtigung erteilen, Daten über Domänen hinweg zu verarbeiten, die aufgrund der Same-Origin Policy ansonsten eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients weiterhin unerwünschte Anfragen blockieren.

X-Powered-By

Kann von Hosting-Umgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über sie, ohne dass dies für die Anwendung oder ihre Besucher von Nutzen ist. Entfernen Sie diesen Header, um potenzielle Schwachstellen zu verbergen.

X-XSS-Protection

Aktiviert das Filtern von Cross-Site-Scripting.

Fetch-Metadatenanforderungs-Header

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

Sec-Fetch-Site

Gibt das Verhältnis zwischen dem Ursprung eines Anforderungsinitiators und dem Zielursprung an. Es ist ein 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 Anforderung an einen Server an. Es ist ein 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 Benutzeraktivierung ausgelöst wurde oder nicht. Es ist ein Structured Header, dessen Wert ein Boolescher Wert 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 ist ein 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 Anforderungsheader sind nicht streng "Fetch-Metadatenanforderungs-Header", bieten aber ähnliche Informationen über den Kontext der Nutzung einer Ressource. Ein Server könnte sie verwenden, um sein Cache-Verhalten zu ändern oder die zurückgegebenen Informationen zu modifizieren:

Sec-Purpose

Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als der unmittelbare Nutzen durch den Benutzer-Agenten ist. Der Header hat derzeit einen möglichen Wert, prefetch, was anzeigt, dass die Ressource vorab für eine mögliche zukünftige Navigation abgerufen wird.

Service-Worker-Navigation-Preload

Ein Anforderungs-Header, der in einer vorzeitigen Anforderung zum fetch() einer Ressource während des Service-Worker-Starts 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 sollte als bei einem normalen fetch()-Vorgang.

Server-sent Events

Reporting-Endpoints

Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, wohin der Browser Warn- und Fehlerberichte beim Verwenden der Reporting API senden soll.

Report-To Veraltet Nicht standardisiert

Antwort-Header, der verwendet wird, um Serverendpunkte anzugeben, wohin der Browser Warn- und Fehlerberichte beim Verwenden der Reporting API senden soll.

Transfer-Codierung

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 Benutzer-Agent akzeptieren kann.

Trailer

Ermöglicht dem Absender, am Ende einer chunked-Nachricht zusätzliche Felder aufzunehmen.

WebSockets

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

Sec-WebSocket-Accept

Antwort-Header, der anzeigt, dass der Server bereit ist, eine WebSocket-Verbindung heraufzustufen.

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 die Eröffnung eines WebSocket beabsichtigt.

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 nicht vom Server unterstützt wird, und listet die Versionen auf, die der Server unterstützt.

Andere

Alt-Svc

Wird verwendet, um alternative Wege aufzulisten, um diesen Dienst zu erreichen.

Alt-Used

Wird verwendet, um den im Einsatz befindlichen alternativen Dienst zu identifizieren.

Date

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

Dieses Entität-Header-Feld bietet eine Möglichkeit zur Serialisierung eines oder mehrerer Links in HTTP-Headern. Es ist semantisch äquivalent zu dem HTML <link>-Element.

Retry-After

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

Server-Timing

Übermittelt ein oder mehrere Metriken und Beschreibungen für den gegebenen Anforderungs-Antwort-Zyklus.

Service-Worker

Wird in Abrufen für das Skriptressourcen eines Service-Workers eingeschlossen. Dieser Header hilft Administratoren, Anfragen nach Service-Worker-Skripten zu protokollieren, um Überwachungszwecke zu erfüllen.

Service-Worker-Allowed

Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header in der Antwort des Service-Worker-Skriptes enthalten ist.

SourceMap

Verlinkt zu einer Source Map, damit Debugger durch den ursprünglichen Quellcode statt durch generierten oder transformierten Code treten können.

Upgrade

Dieser HTTP/1.1- (nur) Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) aufzurüsten. Beispielsweise kann es von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket zu aktualisieren.

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 Clientpriorität anzuzeigen oder in einer Antwort, wenn der Server sich entscheidet, die Anfrage neu zu priorisieren.

Experimentelle Header

Zurechnungsberichte-Header

Das Attribution Reporting API ermöglicht Entwicklern das Messen von Conversions – z. B. wenn ein Benutzer auf eine eingebettete Anzeige auf einer Website klickt und dann das Produkt auf der Website des Verkäufers kauft – und anschließend auf Berichte zu diesen Conversions zuzugreifen. Dies geschieht ohne den Einsatz von Drittanbieter-Cookies, sondern verlässt sich auf verschiedene Header, um Quellen und Auslöser zu registrieren, die übereinstimmen, um eine Conversion anzuzeigen.

Attribution-Reporting-Eligible

Wird verwendet, um anzugeben, dass die Antwort auf die aktuelle Anfrage für die Aufnahme in Zurechnungsberichte durch die Registrierung entweder einer Zurechnungsquelle oder eines Auslösers geeignet ist.

Attribution-Reporting-Register-Source

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

Attribution-Reporting-Register-Trigger

Wird als Teil einer Antwort auf eine Anfrage enthalten, die einen Attribution-Reporting-Eligible-Header enthielt, und wird verwendet, um einen Zurechnungsauslö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, was unter diesen Bedingungen bedient wird, zu optimieren.

Server bitten den Client proaktiv um die Client-Hinweise-Header, an denen sie interessiert sind, über Accept-CH. Der Client kann dann entscheiden, ob er die angeforderten Header in nachfolgenden Anfragen enthalten möchte.

Accept-CH

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

Critical-CH Experimentell

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

Die verschiedenen Arten von Client-Hinweisen sind unten aufgelistet.

Benutzer-Agent-Client-Hinweise

Die UA-Client-Hinweise sind Anforderungsheader, die Informationen über den Benutzer-Agenten, die Plattform/Architektur, auf der er läuft, und Benutzerpräferenzen, die auf dem Benutzer-Agenten oder der Plattform festgelegt sind, bereitstellen:

Sec-CH-UA Experimentell

Marken- und Versionsangaben zum Benutzer-Agenten.

Sec-CH-UA-Arch Experimentell

Architektur der zugrunde liegenden Plattform des Benutzer-Agenten.

Sec-CH-UA-Bitness Experimentell

Bitbreite der zentralen Verarbeitungseinheit (CPU) Architektur des Benutzer-Agenten (z.B. "64" Bit).

Sec-CH-UA-Form-Factors Experimentell

Formfaktoren des Benutzer-Agenten, die beschreiben, wie der Benutzer mit dem Benutzer-Agenten interagiert.

Sec-CH-UA-Full-Version Veraltet

Vollständige Versionszeichenfolge des Benutzer-Agenten.

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

Volle Version für jede Marke in der Liste der Marken des Benutzer-Agenten.

Sec-CH-UA-Mobile Experimentell

Benutzer-Agent läuft auf einem mobilen Gerät oder bevorzugt allgemein eine "mobile" Benutzererfahrung.

Sec-CH-UA-Model Experimentell

Modell des Geräts des Benutzer-Agenten.

Sec-CH-UA-Platform Experimentell

Betriebssystem/Plattform, auf dem der Benutzer-Agent basiert.

Sec-CH-UA-Platform-Version Experimentell

Versionsangabe des Betriebssystems/der Plattform, auf dem/der der Benutzer-Agent basiert.

Sec-CH-UA-WoW64 Experimentell

Ob das Binärprogramm des Benutzer-Agenten im 32-Bit-Modus auf einem 64-Bit-Windows betrieben wird.

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 Layoutverschiebungen von Inhalten zu sehen.

Sec-CH-Prefers-Reduced-Transparency Experimentell

Anforderungs-Header zeigt die Präferenz des Benutzer-Agenten für reduzierte Transparenz an.

Hinweis: Benutzer-Agent-Client-Hinweise sind nicht innerhalb von fenced frames verfügbar, da sie auf Berechtigungsrichtlinien-Delegation beruhen, die verwendet werden könnte, um Daten zu leaken.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert

Antwort-Header, der verwendet wird, um das Bildgerät zum Pixelverhältnis (DPR) in Anfragen zu bestätigen, bei 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 Device Memory API.

DPR Veraltet Nicht standardisiert

Anforderungs-Header, der das Geräte-Pixel-Verhältnis des Clients bereitstellt (die Anzahl physischer Geräte-Pixel für jedes CSS-Pixel).

Viewport-Width Veraltet Nicht standardisiert

Anforderungs-Header, der die Layout-Breite des Clientviewport im CSS-Pixel bereitstellt.

Width Veraltet Nicht standardisiert

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

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise ermöglichen einem Server auszuwählen, welche Informationen basierend auf der Benutzerwahl und der Netzwerkbandbreite und -latenz 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"), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.

RTT Experimentell

Round-Trip-Zeit (RTT) auf Anwendungsebene in Millisekunden, die die Serververarbeitungszeit einschließt. Dies ist Teil der Network Information API.

Save-Data Experimentell

Ein String on, der die Präferenz des Benutzer-Agenten für eine reduzierte Datennutzung anzeigt.

Komprimierungs-Wörterbuchtransport

Komprimierungs-Wörterbuchtransport ist eine Möglichkeit, ein gemeinsames Komprimierungswörterbuch zu verwenden, um die Transportgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch bei Brotli-Komprimierung oder Zstandard-Komprimierung zu verwenden.

Available-Dictionary Experimentell

Ein Browser kann diesen Anforderungs-Header verwenden, um das beste Wörterbuch, das er für die Komprimierung verwenden kann, anzugeben.

Dictionary-ID Experimentell

Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource 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 Übereinstimmungskriterien auf, die das Wörterbuch für zukünftige Anfragen verwenden kann.

Datenschutz

DNT Veraltet Nicht standardisiert

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

Tk Veraltet Nicht standardisiert

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

Sec-GPC Nicht standardisiert Experimentell

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 Experimentell

Antwort-Header, der verwendet wird, um anzugeben, dass das zugehörige Dokument in einem ursprungsbezogenen Agenten-Cluster platziert werden soll. Diese Isolation ermöglicht es Benutzer-Agenten, Implementierungsspezifische Ressourcen für Agenten-Cluster wie Prozesse oder Threads effizienter zuzuweisen.

Server-sent Events

NEL Experimentell

Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Berichterstattungspolitik für Netzwerkfehler zu deklarieren.

Topics API

Die Topics API bietet eine Möglichkeit, Entwicklern die Implementierung von Anwendungsfällen wie interessenbasierte Werbung (IBA) zu ermöglichen. Siehe die Topics API Dokumentation für weitere Informationen.

Observe-Browsing-Topics Experimentell Nicht standardisiert

Antwort-Header, der verwendet wird, um Themen von Interesse, die aus der URL der aufrufenden Website ermittelt wurden, als beobachtet in der Antwort auf eine Anfrage zu markieren, die durch eine Funktion, die die Topics API ermöglicht generiert wurde.

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 werden, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.

Andere

Accept-Signature Experimentell

Ein Client kann das Accept-Signature Header-Feld senden, um die Absicht anzugeben, die Vorteile verfügbarer Signaturen zu nutzen und die unterstützten Signaturarten anzugeben.

Early-Data Experimentell

Gibt an, dass die Anfrage in TLS frühe Daten vermittelt wurde.

Set-Login Experimentell

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

Signature Experimentell

Der Signature Header-Feld übermittelt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität und Erneuerung dieser Signatur zu bestimmen ist.

Signed-Headers Experimentell

Das Signed-Headers Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in einer Signatur enthalten sind.

Speculation-Rules Experimentell

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

Sec-Speculation-Tags Experimentell

Enthält einen oder mehrere Tag-Werte aus den Spekulationsregeln, die die Spekulation verursacht haben, sodass ein Server identifizieren kann, welche Regel(n) eine Spekulation verursacht haben und möglicherweise blockiert werden können.

Supports-Loading-Mode Experimentell

Wird von einem Navigationstarget gesetzt, um die Nutzung verschiedener, risikoreicher Lademodi zu unterstützen. Beispielsweise erfordert die Prerendering-Nutzung über Domänen hinweg, dass Supports-Loading-Mode den Wert credentialed-prerender hat.

Nicht standardmäßige Header

X-Forwarded-For Nicht standardisiert

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

X-Forwarded-Host Nicht standardisiert

Identifiziert den ursprünglichen Host, der von einem Client verwendet wurde, um eine Verbindung zu Ihrem Proxy- oder Lastausgleichsserver herzustellen.

X-Forwarded-Proto Nicht standardisiert

Identifiziert das Protokoll (HTTP oder HTTPS), das von einem Client verwendet wurde, um eine Verbindung zu Ihrem Proxy- oder Lastausgleichsserver herzustellen.

X-DNS-Prefetch-Control Nicht standardisiert

Steuert das DNS-Vorabrufen, ein Feature, bei dem Browser proaktiv die Domain-Name-Auflösung sowohl für Links durchführen, denen der Benutzer folgen könnte, als auch für URLs, die vom Dokument referenziert werden, einschließlich Images, CSS, JavaScript usw.

X-Robots-Tag Nicht standardisiert

Der X-Robots-Tag HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb öffentlicher Suchmaschinenergebnisse indiziert werden soll. Der Header ist gleichwertig zu <meta name="robots">-Elementen.

Veraltete Header

Pragma Veraltet

Implementierungsspezifischer Header, der irgendwo in der Anforderungs-Antwort-Kette verschiedene Auswirkungen haben kann. Wird zur Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, wo der Cache-Control-Header noch nicht vorhanden ist.

Warning Veraltet

Allgemeine Warninformationen über mögliche Probleme.

Siehe auch