HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort auszutauschen. In HTTP/1.X ist ein Header ein nicht case-sensitiver Name, gefolgt von einem Doppelpunkt, dann optionalem Leerzeichen, das ignoriert wird, und abschließend seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header in Kleinbuchstaben angezeigt, wenn sie in den Entwicklertools betrachtet werden (accept: */*), und bei einer speziellen Gruppe von Pseudo-Headern mit einem Doppelpunkt versehen (:status: 200). Sie finden weitere Informationen zur Syntax in jeder Protokollversion 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 eingestellt, die auftraten, wenn nicht standardmäßige Felder im RFC 6648 standardisiert wurden; andere sind im IANA HTTP-Feldnamen-Register aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über deren Status.

Header können nach ihrem Kontext gruppiert werden:

Anfrage-Header: Enthalten zusätzliche Informationen über die Ressource, die abgerufen werden soll, oder über den Client, der die Ressource anfordert.
Antwort-Header: Enthalten zusätzliche Informationen über die Antwort, wie ihren Standort oder über den Server, der sie bereitstellt.
Repräsentations-Header: Enthalten Informationen über den Körper der Ressource, wie seinen MIME-Typ oder die angewendete Kodierung/Kompression.
Nutzlast-Header: Enthalten repräsentationsunabhängige Informationen über Nutzdaten, einschließlich Inhaltlänge und der für den Transport verwendeten Kodierung.

Header können auch nach der Art und Weise gruppiert werden, wie sie von Proxies behandelt werden:

End-to-end-Header: Diese Header müssen an den endgültigen Empfänger der Nachricht übermittelt werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenzeitliche Proxies 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 transportebene Verbindung von Bedeutung und dürfen nicht von Proxies weiterübermittelt oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-hop-Header mit dem Connection-Header festgelegt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die zur Zugriffssteuerung auf eine Ressource verwendet werden sollte.
Authorization: Enthält die Anmeldedaten zur Authentifizierung eines Benutzeragents mit einem Server.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die zur Zugriffssteuerung auf eine Ressource hinter einem Proxyserver verwendet werden sollte.
Proxy-Authorization: Enthält die Anmeldedaten zur Authentifizierung eines Benutzeragents mit einem Proxyserver.

Zwischenspeicherung

Age: Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache verbracht hat.
Cache-Control: Direktiven für Caching-Mechanismen sowohl in Anfragen als auch in Antworten.
Clear-Site-Data: Löscht Browsing-Daten (z. B. Cookies, Speicher, Cache), die mit der anfragenden Website verbunden sind.
Expires: Das Datum/Uhrzeit, nach dem die Antwort als veraltet betrachtet wird.
No-Vary-Search Experimentell: Gibt eine Reihe von Regeln an, die definieren, wie die Abfrageparameter einer URL das Cache-Matching beeinflussen. Diese Regeln bestimmen, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Cache-Einträge im Browser gespeichert wird.

Bedingungen

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, die If-Modified-Since und If-Unmodified-Since verwenden, nutzen diesen Wert, um das Verhalten der Anfrage zu ändern.
ETag: Eine eindeutige Zeichenkette zur Identifizierung der Version der Ressource. 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 das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine existiert.
If-Modified-Since: Macht die Anfrage bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum geändert wurde. Dies wird verwendet, um Daten nur zu übertragen, wenn der Cache 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 sichert die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit früheren, oder implementiert ein optimistisches Konkurrenzkontrollsystem bei der Modifikation bestehender Dokumente.
Vary: Bestimmt, wie Anforderungsheader abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine frische vom Ursprung-Server anzufordern.

Verbindungsmanagement

Connection: Steuert, ob die Netzwerkverbindung geöffnet bleibt, nachdem die aktuelle Transaktion abgeschlossen ist.
Keep-Alive: Steuert, wie lange eine persistente Verbindung geöffnet bleiben sollte.

Inhaltsverhandlung

Für weitere Einzelheiten lesen Sie den Artikel zur Inhaltsverhandlung.

Accept: Informiert den Server über die Typen von Daten, die zurückgesendet werden können.
Accept-Encoding: Der Kodierungsalgorithmus, in der Regel 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 liegt nicht unbedingt vollständig unter der Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.
Accept-Patch: Ein Anfrageinhalt-Verhandlung-Antwort-Header, der die Medientypen angibt, die der Server bei einer PATCH-Anfrage verstehen kann.
Accept-Post: Ein Anfrageinhalt-Verhandlung-Antwort-Header, der die Medientypen angibt, die der Server bei einer POST-Anfrage verstehen kann.

Steuerungen

Expect: Gibt Erwartungen an, die der Server erfüllen muss, um die Anfrage ordentlich zu bearbeiten.
Max-Forwards: Gibt bei der Verwendung von TRACE die maximale Anzahl der Sprünge an, die die Anfrage machen kann, bevor sie an den Absender reflektiert wird.

Cookies

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 Benutzeragenten.

CORS

Für mehr Informationen siehe die CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Credential-Flag wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Voranfrage verwendet, um anzugeben, 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 Voranfrage erlaubt sind.
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 Voranfrage zwischengespeichert werden können.
Access-Control-Request-Headers: Wird bei der Ausstellung einer Voranfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird bei der Ausstellung einer Voranfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode bei der tatsächlichen Anfrage verwendet wird.
Origin: Gibt an, woher ein Abruf stammt.
Timing-Allow-Origin: Gibt Ursprünge an, die berechtigte Werte von Attributen sehen dürfen, die über Funktionen der Resource Timing API abgerufen werden, die sonst aufgrund von Cross-Origin-Beschränkungen als Null gemeldet werden 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 ein "Speichern unter"-Dialogfeld anzeigen soll.

Integritäts-Digests

Content-Digest Experimentell: Bietet einen Digest des Oktettstroms, der in einer HTTP-Nachricht umrahmt wird (der Nachrichteninhalt), 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 Content-Encoding oder Content-Range nicht.
Want-Content-Digest Experimentell: Gibt den Wunsch nach einem Content-Digest-Header an. Es ist das Content--Analogon von Want-Repr-Digest.
Want-Repr-Digest Experimentell: Gibt den Wunsch nach einem Repr-Digest-Header an. Es ist das Repr--Analogon von Want-Content-Digest.

Integritätspolitik

Integrity-Policy: Stellt sicher, dass alle vom Benutzeragenten geladenen Ressourcen (eines bestimmten Typs) Garantien der Subresource Integrity haben.
Integrity-Policy-Report-Only: Erstellt Berichte über Ressourcen, die der Benutzeragent lädt, und die Leistungsoptionen Subresource Integrity-Garantie verletzen würden, wenn die Integritätspolitik durchgesetzt würde (unter Verwendung des Integrity-Policy-Headers).

Nachrichtentextinformationen

Content-Length: Die Größe der Ressource in dezimaler Anzahl von Bytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Wird verwendet, um den Kompressionsalgorithmus anzugeben.
Content-Language: Beschreibt die menschliche Sprache(n), die für das Publikum bestimmt sind, damit ein Benutzer nach der bevorzugten Sprache des Benutzers 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 wird, falls es sonst für den Client mehrdeutig 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 Anfrageverarbeitung an. Zum Beispiel kann Minimalantwortinhalt (return=minimal) oder asynchrone Verarbeitung (respond-async) angefordert werden. Der Server verarbeitet die Anfrage normal, wenn der Header nicht unterstützt wird.
Preference-Applied: Informiert den Client darüber, welche im Prefer-Header spezifizierten Präferenzen vom Server angewendet wurden. Es ist ein nur für Antworten gültiger Header, der Transparenz über die Präferenzbehandlung bietet.

Proxies

Forwarded: Enthält Informationen von der clientseitigen Seite von Proxy-Servern, die verändert oder verloren gehen, wenn ein Proxy auf dem Weg der Anfrage beteiligt ist.
Via: Wird von Proxies hinzugefügt, sowohl von Forward- als auch Reverse-Proxies, und kann in den Anfragen- und 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 nur einen Teil einer großen Datei benötigen, und Download-Manager, die dem Benutzer erlauben, einen Download zu pausieren und fortzusetzen.

Accept-Ranges: Gibt 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 das gegebene ETag oder Datum mit der entfernten Ressource übereinstimmt. Verhindert das Herunterladen von zwei Bereichen aus inkompatiblen Versionen der Ressource.
Content-Range: Gibt an, wo in einer vollständigen Nachricht ein Teil einer Nachricht dazugehört.

Weiterleitungen

Location: Gibt die URL an, zu der eine Seite weitergeleitet werden soll.
Refresh: Weist den Browser an, die Seite neu zu laden oder zu einer anderen weiterzuleiten. 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 Benutzeragenten 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 derzeit angeforderten Seite gefolgt wurde.
Referrer-Policy: Regelt, welche Referrer-Informationen im Referer-Header mit den Anfragen gesendet werden sollen.
User-Agent: Enthält eine charakteristische Zeichenkette, die es den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfordernden Software-Benutzeragenten zu identifizieren.

Antwortkontext

Allow: Listet die Gruppe von 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 es einem Server, eine Einbettungspolitik für ein bestimmtes Dokument zu deklarieren.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domains ein Fenster öffnen/kontrollieren.
Cross-Origin-Resource-Policy (CORP): Verhindert, dass andere Domains die Antwort auf die Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch CORP-Erklärungsartikel.
Content-Security-Policy (CSP): Steuert Ressourcen, die der Benutzeragent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Ermöglicht Webentwicklern, mit Richtlinien zu experimentieren, indem die Auswirkungen überwacht, aber nicht durchgesetzt werden. 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 Berichterstattung und Durchsetzung von Certificate Transparency zu entscheiden, um die Verwendung falsch ausgestellter Zertifikate für diese Website zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Nutzung von Browserfunktionen im eigenen Frame einer Website zu erlauben oder zu verweigern, sowie in <iframe>s, die sie einbettet.
Reporting-Endpoints Experimentell: Antwortheader, der Website-Besitzern erlaubt, einen oder mehrere Endpunkte zu spezifizieren, die verwendet werden, um Fehler wie CSP-Verstoßberichte, Cross-Origin-Opener-Policy-Berichte oder andere generische Verstöße zu empfangen.
Strict-Transport-Security (HSTS): Erzwingen Sie 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 erfolgreich mit der upgrade-insecure-requests-Direktive umgehen 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 erlaubt werden sollte, eine Seite in einem <frame>, <iframe>, <embed> oder <object> darzustellen.
X-Permitted-Cross-Domain-Policies: Eine bereichsübergreifende Richtliniendatei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderen) die Erlaubnis erteilen, Daten über Domains hinweg zu verarbeiten, die sonst aufgrund der Same-Origin-Policy eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients trotzdem unerwünschte Anfragen blockieren.
X-Powered-By: Kann von Hostingumgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, während es keine Nützlichkeit für die Anwendung oder ihre Besucher bietet. Setzen Sie diesen Header ab, um potenzielle Schwachstellen offenzulegen.
X-XSS-Protection: Aktiviert die Filterung von Cross-Site-Scripting.

Fetch-Metadatenanforderungsheader

Fetch-Metadatenanforderungsheader liefern Informationen über den Kontext, aus dem die Anforderung stammt. Ein Server kann sie verwenden, um Entscheidungen darüber zu treffen, ob eine Anforderung zugelassen werden soll, basierend darauf, woher die Anforderung kam und wie die Ressource verwendet wird.

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprung eines Anforderungsinitiators und dem Zielursprung an. Es ist ein strukturierter 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 strukturierter 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 strukturierter Header, dessen Wert ein Boolescher Wert ist, sodass mögliche Werte ?0 für false und ?1 für true sind.
Sec-Fetch-Dest: Gibt das Ziel der Anforderung an. Es ist ein strukturierter 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 genommen "Fetch-Metadatenanforderungsheader", liefern jedoch ebenso Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten zu ändern oder die zurückgegebenen Informationen:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes ist als die unmittelbare Verwendung durch den Benutzeragenten. Der Header hat derzeit einen möglichen Wert, prefetch, der angibt, dass die Ressource vorsorglich für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungsheader, der in vorsorglichen Anfragen verwendet wird, um eine Ressource während des Starts eines Service-Workers mit fetch() abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource zurückgegeben werden sollte als in einer normalen fetch()-Operation.

Server-gesendete Ereignisse

Reporting-Endpoints: Antwortheader, der verwendet wird, um Server-Endpunkte zu spezifizieren, wohin der Browser bei der Verwendung der Reporting-API Warn- und Fehlerberichte senden soll.
Report-To Veraltet Nicht standardisiert: Antwortheader, der verwendet wird, um Server-Endpunkte zu spezifizieren, wohin der Browser bei der Verwendung der Reporting-API Warn- und Fehlerberichte senden soll.

Übertragungscodierung

Transfer-Encoding: Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher zum Benutzer zu übertragen.
TE: Gibt die Übertragungscodierungen an, die der Benutzeragent akzeptiert.
Trailer: Erlaubt es dem Absender, zusätzliche Felder am Ende einer segmentierten Nachricht einzufügen.

WebSockets

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

Sec-WebSocket-Accept: Antwortheader, der anzeigt, dass der Server bereit ist, zu einer WebSocket-Verbindung zu wechseln.
Sec-WebSocket-Extensions: In Anfragen zeigt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten zeigt er die vom Server aus den Präferenzen des Clients ausgewählte Erweiterung an.
Sec-WebSocket-Key: Anforderungsheader, der einen Schlüssel enthält, der bestätigt, dass der Client explizit beabsichtigt, ein WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen zeigt dieser Header die unterstützten Subprotokolle des Clients in bevorzugter Reihenfolge an. In Antworten zeigt er das vom Server aus den Präferenzen des Clients ausgewählte Subprotokoll an.
Sec-WebSocket-Version: In Anfragen zeigt 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.

Andere

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 Entitäten-Headerfeld bietet eine Möglichkeit zur Serialisierung eines oder mehrerer Links in HTTP-Headern. Es ist semantisch äquivalent zum HTML-Element <link>.
Retry-After: Gibt an, wie lange der Benutzeragent 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 Abrufen für das Skriptressourcen eines Service-Workers enthalten. Dieser Header hilft Administratoren, Anfragen von Service-Worker-Skripten für Überwachungszwecke zu protokollieren.
Service-Worker-Allowed: Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header in die Antwort des Service-Worker-Skripts aufgenommen wird.
SourceMap: Verlinkt zu einer Quellkarte, damit Debugger durch den ursprünglichen Quellcode anstelle von generiertem oder transformiertem Code navigieren können.
Upgrade: Dieser HTTP/1.1 (nur)-Header kann verwendet werden, um eine bereits etablierte Client-/Server-Verbindung zu einem anderen Protokoll (über dasselbe Transportprotokoll) hochzustufen. Zum Beispiel kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 zu HTTP 2.0 hochzustufen oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket.
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 die Anfrage neu priorisieren möchte.

Experimentelle Header

Attributionsberichte-Header

Die Attributions-Reporting-API ermöglicht es Entwicklern, Konversionen zu messen – zum Beispiel wenn ein Benutzer auf eine in eine Seite eingebettete Anzeige klickt und dann das Produkt auf der Website des Anbieters kauft – und dann Berichte über diese Konversionen zuzugreifen. Dies geschieht ohne die Verwendung von Drittanbieter-Tracking-Cookies, sondern stützt sich auf verschiedene Header, um Quellen und Trigger zu registrieren, die zusammengebracht werden, um eine Konversion anzuzeigen.

Attribution-Reporting-Eligible: Wird verwendet, um anzuzeigen, dass die Antwort auf die aktuelle Anfrage berechtigt ist, an Attributionsberichten teilzunehmen, indem entweder eine Attributionquelle oder ein Trigger registriert wird.
Attribution-Reporting-Register-Source: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, verwendet, um eine Attributionquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Wird als Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt, verwendet, um einen Attributiontrigger zu registrieren.

Client-Hinweise

HTTP Client-Hinweise sind eine Gruppe von Anforderungs-Headern, die nützliche Informationen über den Client liefern wie Gerätetyp und Netzwerkbedingungen und es Servern ermöglichen, das, was für diese Bedingungen serviert wird, zu optimieren.

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

Accept-CH: Server können die Unterstützung für Client-Hinweise mithilfe des Headerfeldes Accept-CH oder eines entsprechenden HTML-<meta>-Elements mit dem Attribut http-equiv bewerben.
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.

Benutzeragent-Client-Hinweise

Die UA-Client-Hinweise sind Anforderungs-Header, die Informationen über den Benutzeragenten, die Plattform/Architektur, auf der er läuft, und vom Benutzeragenten oder Plattform gesetzte Benutzerpräferenzen liefern:

Sec-CH-UA Experimentell: Benutzeragent-Marken und Version.
Sec-CH-UA-Arch Experimentell: Plattformarchitektur des Benutzeragenten.
Sec-CH-UA-Bitness Experimentell: CPU-Architektur-Bitness des Benutzeragenten (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factors Experimentell: Form-Faktoren des Benutzeragenten, die beschreiben, wie der Benutzer mit dem Benutzeragenten interagiert.
Sec-CH-UA-Full-Version Veraltet: Vollständiger Versionsstring des Benutzeragenten.
Sec-CH-UA-Full-Version-List Experimentell: Vollständige Version für jede Marke in der Markenliste des Benutzeragenten.
Sec-CH-UA-Mobile Experimentell: Der Benutzeragent läuft auf einem mobilen Gerät oder bevorzugt im Allgemeinen eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model Experimentell: Gerätemodell des Benutzeragenten.
Sec-CH-UA-Platform Experimentell: Betriebssystem/Plattform des Benutzeragenten.
Sec-CH-UA-Platform-Version Experimentell: Betriebssystemversion des Benutzeragenten.
Sec-CH-UA-WoW64 Experimentell: Ob das Benutzeragentenprogramm im 32-Bit-Modus auf 64-Bit-Windows läuft.
Sec-CH-Prefers-Color-Scheme Experimentell: Präferenz des Benutzers für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion Experimentell: Präferenz des Benutzers, weniger Animationen und Layout-Verschiebungen von Inhalten zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anfrage-Header gibt die Präferenz des Benutzeragenten für reduzierte Transparenz an.

Hinweis: Benutzeragent-Client-Hinweise sind in fenced frames nicht verfügbar, da sie auf der Erlaubnisrichtlinie-Delegation beruhen, die verwendet werden könnte, um Daten zu leaken.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert: Antwort-Header, der in Anfragen, in denen der Bildschirm client-Hinweis DPR verwendet wurde, das Bildgerät-zu-Pixel-Verhältnis (DPR) bestätigt, um eine Bildressource auszuwählen.
Device-Memory: Ungefähre Menge des verfügbaren RAM-Speicherplatzes des Clients. Dies ist Teil der Device Memory API.
DPR Veraltet Nicht standardisiert: Anfrage-Header, der das clientseitige Geräte-Pixel-Verhältnis liefert (die Anzahl physischer Gerätepixel für jedes CSS-Pixel).
Viewport-Width Veraltet Nicht standardisiert: Anfrage-Header gibt die Layout-Viewport-Breite des Clients in CSS-Pixel an.
Width Veraltet Nicht standardisiert: Anfrage-Header gibt die gewünschte Breite der Ressource in physischen Pixeln an (die intrinsische Größe eines Bildes).

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise ermöglichen es einem Server, auszuwählen, welche Informationen basierend auf der Benutzerwahl und der Netzwerkbandbreite und -latenz gesendet werden.

Downlink Experimentell: Ungefähre Bandbreite der Verbindung des Clients zum Server in MBit/s. 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: RTT (Round-Trip Time) auf Anwendungsschicht in Millisekunden, die auch die Serververarbeitungszeit umfasst. Dies ist Teil der Network Information API.
Save-Data Experimentell: Ein String on, der die Präferenz des Benutzeragenten anzeigt, weniger Daten zu verwenden.

Kompressionswörterbuch-Transport

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

Available-Dictionary Experimentell: Ein Browser kann diesen Anforderungs-Header verwenden, um das beste verfügbare Wörterbuch anzugeben, das der Server für die Kompression verwenden soll.
Dictionary-ID Experimentell: Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource 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 Dictionary-id im Dictionary-ID-Header.
Use-As-Dictionary Experimentell: Listet die Abgleichskriterien auf, für die das Wörterbuch bei zukünftigen Anfragen verwendet werden kann.

Datenschutz

DNT Veraltet Nicht standardisiert: Anfrage-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Veraltet zugunsten der Global Privacy Control (GPC), die mithilfe des Sec-GPC-Headers an Server kommuniziert wird und für Clients über navigator.globalPrivacyControl zugänglich ist.
Tk Veraltet Nicht standardisiert: Antwortheader, 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 einem Verkauf oder Teilen seiner persönlichen Informationen durch eine Website oder einen Dienst mit Dritten einwilligt.

Sicherheit

Origin-Agent-Cluster Experimentell: Antwortheader, der verwendet wird, um anzugeben, dass das zugehörige Dokument in einem Ursprungs-gebundenen Agenten-Cluster platziert werden soll. Diese Isolierung ermöglicht es Benutzeragenten, implementationsspezifischen Ressourcen für Agenten-Cluster effizienter zuzuordnen, wie Prozesse oder Threads.

Server-gesendete Ereignisse

NEL Experimentell: Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Netzwerkfehlerberichtspolitik zu deklarieren.

Themen-API

Die Themen-API bietet einen Mechanismus für Entwickler, um Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. Lesen Sie die Themen-API-Dokumentation für weitere Informationen.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwortheader, der verwendet wird, um markierte Themen, die aus der URL einer aufrufenden Seite im Response auf eine Anfrage gelöscht werden, die von einer Funktion, die die Themen-API aktiviert, abgeleitet wurden.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Anfrage-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der verbundenen Anfrage sendet, die von einer Werbetechnikplattform verwendet werden, um eine personalisierte Anzeige auszuwählen, die angezeigt wird.

Andere

Accept-Signature Experimentell: Ein Client kann das Accept-Signature-Headerfeld senden, um die Absicht anzuzeigen, Verfügbarkeitssignaturen zu nutzen und anzugeben, welche Arten von Signaturen es unterstützt.
Early-Data Experimentell: Gibt an, dass die Anfrage in TLS-Vordaten übermittelt wurde.
Idempotency-Key Experimentell: Bietet einen einzigartigen Schlüssel für POST- und PATCH-Anfragen, der es ermöglicht, diese idempotent auszuführen.
Set-Login Experimentell: Antwortheader, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, was bedeutet, ob irgendwelche Benutzer im IdP im aktuellen Browser angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM-API verwendet.
Signature Experimentell: Das Signature-Headerfeld überträgt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität bestimmt und diese Signatur aktualisiert wird.
Signed-Headers Experimentell: Das Signed-Headers-Headerfeld identifiziert eine geordnete Liste von Antwort-Headerfeldern, die in eine Signatur einbezogen werden.
Speculation-Rules Experimentell: Bietet eine Liste von URLs, die auf Textressourcen zeigen, die Raumregeln-JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregelsatz des Dokuments hinzugefügt.
Sec-Speculation-Tags Experimentell: Enthält einen oder mehrere Tag-Werte aus den Spekulationsregeln, die zur Spekulation geführt haben, damit ein Server identifizieren kann, welche Regel(n) eine Spekulation verursacht haben und sie möglicherweise blockieren.
Supports-Loading-Mode Experimentell: Wird von einem Navigationsziel gesetzt, um sich für die Nutzung verschiedener höher-riskanter Lade-Modi zu entscheiden. Zum Beispiel erfordert das Cross-Origin-, Same-Site-Prerendering](/de/docs/Web/API/Speculation_Rules_API#using_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 zu einem Webserver verbindet.
X-Forwarded-Host Nicht standardisiert: Identifiziert den ursprünglichen Host, der angefordert wurde, den ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Lastverteiler herzustellen.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Lastverteiler herzustellen.
X-DNS-Prefetch-Control Nicht standardisiert: Steuert das DNS-Prefetching, eine Funktion, bei der Browser proaktiv domainnameauflösung sowohl für Links, die der Benutzer möglicherweise verfolgt, als auch URLs für Elemente, 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 in öffentlichen Suchmaschinenergebnissen indiziert werden soll. Der Header ist äquivalent zu <meta name="robots">-Elementen.

Veraltete Header

Pragma Veraltet: Implementierungsspezifischer Header, der entlang der Anforderung-Reaktions-Kette verschiedene Effekte haben kann. Wird für die Rückwä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

Help improve MDN

Learn how to contribute Diese Seite wurde automatisch aus dem Englischen übersetzt.

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