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 eine nicht auf Groß-/Kleinschreibung achtende Bezeichnung, gefolgt von einem Doppelpunkt, dann optionalem Leerraum, der ignoriert wird, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header in Kleinbuchstaben angezeigt, wenn sie in Entwickler-Tools betrachtet werden (accept: */*), und mit einem Doppelpunkt für eine spezielle Gruppe von Pseudo-Headern versehen (:status: 200). Mehr 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 entstanden, als nicht standardmäßige Felder in RFC 6648 zu Standardfeldern wurden, abgelehnt; weitere sind im IANA HTTP Field Name Registry aufgelistet, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf und enthält Informationen über ihren Status.

Header können nach ihrem Kontext gruppiert werden:

Anfrage-Header: Enthalten zusätzliche Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.
Antwort-Header: Enthalten zusätzliche Informationen über die Antwort, wie zum Beispiel ihren Standort oder über den Server, der sie bereitstellt.
Darstellungs-Header: Enthalten Informationen über den Hauptteil der Ressource, wie ihren MIME-Typ oder angewendete Kodierung/Kompression.
Lastdaten-Header: Enthalten darstellungsunabhängige Informationen über Lastdaten, einschließlich Inhaltslänge und Kodierung, die für den Transport verwendet wird.

Header können auch danach gruppiert werden, wie Proxyserver sie behandeln:

End-to-end-Header: Diese Header müssen an den Endempfänger der Nachricht übertragen werden: der Server für eine Anfrage oder der Client für eine Antwort. Zwischenproxies müssen diese Header unverändert weiterleiten und Caches müssen sie speichern.
Hop-by-hop-Header: Diese Header sind nur für eine einzelne Transportverbindung auf niedrigster Ebene von Bedeutung und dürfen nicht von Proxies weitergeleitet oder gecached werden. Beachten Sie, dass nur Hop-by-hop-Header mit dem Header Connection gesetzt werden können.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden sollte.
Authorization: Enthält die Anmeldedaten zur Authentifizierung eines Benutzer-Agents beim Server.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource hinter einem Proxyserver verwendet werden sollte.
Proxy-Authorization: Enthält die Anmeldedaten zur Authentifizierung eines Benutzer-Agents bei einem Proxyserver.

Caching

Age: Die Zeit, in Sekunden, die das Objekt im Proxy-Cache war.
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 denen die Antwort als veraltet angesehen wird.
No-Vary-Search: Gibt eine Reihe von Regeln an, die definieren, wie sich die Abfrageparameter einer URL auf das Cache-Matching auswirken. Diese Regeln diktieren, ob die gleiche URL mit verschiedenen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden sollte.

Konditionen

Last-Modified: Das Datum der letzten Änderung der Ressource, das verwendet wird, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau als ETag, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anfragen mit If-Modified-Since und If-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.
ETag: Eine eindeutige Zeichenfolge, die die Version der Ressource identifiziert. Bedingte Anfragen mit If-Match und If-None-Match verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.
If-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.
If-None-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource nicht mit einem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen) oder um 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 modifiziert 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 modifiziert wurde. Dies stellt die Kohärenz eines neuen Fragments eines spezifischen Bereichs mit früheren sicher oder dient zur Implementierung eines Systems zur optimistischen Nebenläufigkeitskontrolle bei der Modifikation bestehender Dokumente.
Vary: Bestimmt, wie Anfrage-Header abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine frische vom Origin-Server anzufordern.

Verbindungsmanagement

Connection: Steuert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion geöffnet bleibt.
Keep-Alive: Steuert, wie lange eine persistente Verbindung geöffnet bleiben soll.

Inhaltsverhandlung

Weitere Details finden Sie im Artikel zur Inhaltsverhandlung.

Accept: Informiert den Server über die Typen von Daten, die zurückgesandt werden können.
Accept-Encoding: Der Kodierungsalgorithmus, meist ein Kompressionsalgorithmus, der für die zurückgesandte Ressource verwendet werden kann.
Accept-Language: Informiert den Server über die Menschensprache, die der Server zurücksenden soll. Dies ist ein Hinweis und liegt nicht notwendigerweise vollständig unter der Kontrolle des Benutzers: der Server sollte immer darauf achten, die explizite Benutzerwahl (wie zum Beispiel eine Sprache aus einem Dropdown-Menü zu wählen) nicht zu überschreiben.
Accept-Patch: Ein request content negotiation Antwort-Header, der angibt, welchen Medientyp der Server in einer PATCH Anfrage verstehen kann.
Accept-Post: Ein request content negotiation Antwort-Header, der angibt, welchen Medientyp der Server in einer POST Anfrage verstehen kann.

Steuerungsmechanismen

Expect: Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.
Max-Forwards: Bei Verwendung von TRACE gibt es die maximale Anzahl von Sprüngen an, die die Anfrage machen kann, bevor sie an den Absender zurückgespiegelt 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 Benutzer-Agent.

CORS

Weitere Informationen finden Sie in der CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das Credential-Flag true ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden können.
Access-Control-Allow-Methods: Gibt die Methoden an, die beim Zugriff auf die Ressource als Antwort auf eine Preflight-Anfrage 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 Preflight-Anfrage im Cache bleiben können.
Access-Control-Request-Headers: Wird bei der Erstellung einer Preflight-Anfrage verwendet, um den Server wissen zu lassen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird bei der Erstellung einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode bei der tatsächlichen Anfrage verwendet wird.
Origin: Gibt an, woher ein Fetch stammt.
Timing-Allow-Origin: Gibt Ursprünge an, denen es erlaubt ist, Werte von Attributen abzurufen, die über Funktionen der Resource Timing API abgerufen werden, die andernfalls aufgrund von Cross-Origin-Beschränkungen als Null berichtet 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 sollte.

Integritäts-Hashes

Content-Digest: Bietet einen Digest des Streams von Oktetten, die in einer HTTP-Nachricht gerahmt sind (der Nachrichtinhalt), abhängig von Content-Encoding und Content-Range.
Repr-Digest: Bietet einen Digest der gewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zum Content-Digest wird bei diesem Digest Content-Encoding oder Content-Range nicht berücksichtigt.
Want-Content-Digest: Gibt den Wunsch nach einem Content-Digest Header an. Es ist das Content- Analogon von Want-Repr-Digest.
Want-Repr-Digest: Gibt den Wunsch nach einem Repr-Digest Header an. Es ist das Repr- Analogon von Want-Content-Digest.

Integritätsrichtlinie

Integrity-Policy: Stellt sicher, dass alle vom Benutzer-Agent geladenen Ressourcen (einer bestimmten Art) Subresource Integrity Garantien haben.
Integrity-Policy-Report-Only: Berichtet über Ressourcen, die der Benutzer-Agent lädt und die die Subresource Integrity Garantien verletzen würden, wenn die Integritätsrichtlinie durchgesetzt würde (unter Verwendung des Integrity-Policy Headers).

Nachrichtenkörperinformationen

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 für das Publikum vorgesehene menschliche Sprache(n), sodass ein Benutzer eigene bevorzugte Sprache(n) 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 anzugeben. Die Serverantwort kann angeben, ob eine Präferenz angewandt wurde, in Fällen, in denen es andernfalls für den Client unklar wäre. Browser haben keine native Handhabung für das Senden von Präferenzen über diese Header; sie werden in benutzerdefinierten, implementation-specific Clients verwendet.

Prefer: Gibt Präferenzen für spezifische Serververhaltensweisen während der Anfrageverarbeitung an. Zum Beispiel kann er 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 im Prefer Header angegebenen Präferenzen vom Server angewandt wurden. Es ist ein reiner Antwort-Header, der Transparenz über die Präferenzbehandlung bietet.

Proxies

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

Range-Anfragen

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

Accept-Ranges: Gibt an, ob der Server Range-Anfragen unterstützt und 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 Range-Anfrage, die nur erfüllt wird, wenn der angegebene ETag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um zu verhindern, dass zwei Bereiche von unvereinbaren Versionen der Ressource heruntergeladen werden.
Content-Range: Gibt an, wo in einer vollständigen Nachricht ein Teilnachricht gehört.

Weiterleitungen

Location: Gibt die URL an, zu der eine Seite weitergeleitet werden soll.
Refresh: Weist den Browser an, die Seite neu zu laden oder zu einer anderen umzuleiten. Hat denselben Wert wie das meta Element mit http-equiv="refresh".

Anfragkontext

From: Enthält eine Internet-E-Mail-Adresse eines menschlichen Nutzers, der den anfordernden Benutzer-Agent steuert.
Host: Gibt den Domänennamen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server lauscht.
Referer: Die Adresse der vorherigen Webseite, von der ein Link zur aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy: Bestimmt, welche Referrer-Informationen im Referer Header mit gesendeten Anfragen enthalten sein sollen.
User-Agent: Enthält eine charakteristische Zeichenfolge, die es den Netzwerkprotokollpartnern ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfragenden Software-Agents zu identifizieren.

Antwortkontext

Allow: Listet die HTTP-Anfragemethoden auf, die von einer Ressource unterstützt werden.
Server: Enthält Informationen über die Software, die vom Ursprungsserver zur Bearbeitung der Anfrage verwendet wird.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Erlaubt einem Server, eine Einbettungspolitik für ein bestimmtes Dokument zu erklären.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domänen ein Fenster öffnen/steuern.
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): Steuert Ressourcen, die der Benutzer-Agent für eine Seite laden darf.
Content-Security-Policy-Report-Only: Ermöglicht es Webentwicklern, mit Richtlinien zu experimentieren, indem sie ihre Auswirkungen überwachen, aber nicht erzwingen. Diese Verstoßberichte bestehen aus JSON Dokumenten, die über eine HTTP POST Anfrage an die angegebene URI gesendet werden.
Expect-CT: Ermöglicht es Websites, das Reporting und die Durchsetzung von Zertifikatstransparenz zu aktivieren, um die Verwendung von fehlerhaft ausgestellten Zertifikaten für diese Website zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Verwendung von Browserfunktionen in einem eigenen Frame einer Website und in <iframe>s, die sie einbettet, zu erlauben und zu verweigern.
Reporting-Endpoints: Antwort-Header, der es Website-Eigentümern ermöglicht, einen oder mehrere Endpunkte für den Empfang von Fehlern wie CSP-Verstoßmeldungen, Cross-Origin-Opener-Policy Berichten oder anderen allgemeinen Verstößen anzugeben.
Strict-Transport-Security (HSTS): Erzwingt die Kommunikation über HTTPS anstelle von HTTP.
Upgrade-Insecure-Requests: Sendet ein Signal an den Server, um die Bevorzugung eines verschlüsselten und authentifizierten Antworts auszudrücken und zeigt an, dass der Client die upgrade-insecure-requests Direktive erfolgreich bearbeiten 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 eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern darf.
X-Permitted-Cross-Domain-Policies: Eine richtlinienübergreifende Datei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderen) die Erlaubnis geben, Daten über Domänen hinweg zu behandeln, die andernfalls aufgrund der Identitätsursprungsrichtlinie eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies Header überschreibt solche Richtliniendateien, 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 es keine Nützlichkeit für die Anwendung oder ihre Besucher bietet. Deaktivieren Sie diesen Header, um potenzielle Schwachstellen nicht offenzulegen.
X-XSS-Protection: Aktiviert das Filtern von Cross-Site-Scripting.

Fetch-Metadaten-Anfrage-Header

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

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprungsinitiator einer Anfrage 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 Anfrage 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 Boolean ist, sodass mögliche Werte ?0 für false und ?1 für true sind.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage 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 Anfrage-Header sind nicht streng "Fetch-Metadaten-Anfrage-Header", bieten aber ähnlich Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Caching-Verhalten zu ändern oder die Informationen, die zurückgegeben werden:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als die sofortige Verwendung durch den Benutzer-Agent ist. Der Header hat derzeit einen möglichen Wert, prefetch, der anzeigt, dass die Ressource präventiv für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anfrage-Header, der in präventiver Anfrage gesendet wird, um fetch() eine Ressource während des Startvorgangs des Service-Workers zu holen. 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.

Fetch-Speicherzugriffs-Header

Diese Header ermöglichen einen verbesserten Workflow für die Storage Access API.

Sec-Fetch-Storage-Access: Gibt den "Speicherzugriffsstatus" für den aktuellen Abrufkontext an, der einer von none, inactive oder active sein wird. Der Server kann mit Activate-Storage-Access antworten, um zu verlangen, dass der Browser eine inactive Berechtigung aktiviert und die Anfrage erneut versucht oder eine Ressource mit Zugriff auf seine Drittanbieter-Cookies lädt, wenn der Status active ist.
Activate-Storage-Access: Wird in Antwort auf Sec-Fetch-Storage-Access verwendet, um anzuzeigen, dass der Browser eine bestehende Berechtigung für sicheren Zugriff aktivieren und die Anfrage mit Cookies erneut versuchen oder eine Ressource mit Cookie-Zugriff laden kann, wenn bereits eine aktivierte Berechtigung besteht.

Server-gesendete Ereignisse

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

Transcodierung der Übertragung

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 zu akzeptieren bereit ist.
Trailer: Ermöglicht dem Absender, zusätzliche Felder am Ende einer chunked-Nachricht hinzuzufügen.

WebSockets

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

Sec-WebSocket-Accept: Antwort-Header, der angibt, dass der Server bereit ist, eine WebSocket-Verbindung hochzustufen.
Sec-WebSocket-Extensions: In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten WebSocket-Erweiterungen an. In Antworten gibt er die vom Server aus den Client-Vorlieben ausgewählte Erweiterung an.
Sec-WebSocket-Key: Anfrage-Header, der einen Schlüssel enthält, der bestätigt, dass der Client explizit die Öffnung eines WebSocket beabsichtigt.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten Sub-Protokolle an. In Antworten gibt er das vom Server aus den Client-Vorlieben 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 vom Server nicht unterstützt wird, und listet die Versionen, die der Server unterstützt, auf.

Andere

Alt-Svc: Wird verwendet, um alternative Wege aufzulisten, um diesen Service zu erreichen.
Alt-Used: Wird verwendet, um den alternativ verwendeten Service zu identifizieren.
Date: Enthält das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde.
Link: Dieses Entity-Header-Feld bietet eine Möglichkeit, einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML <link> Element.
Retry-After: Gibt an, wie lange der Benutzer-Agent warten sollte, bevor er eine Folgeanfrage stellt.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anforderungs-Antwort-Zyklus.
Service-Worker: Wird in Fetches für das Script-Resource eines Service-Workers enthalten. Dieser Header hilft Administratoren, Anfragen für Service-Worker-Scripts zu protokollieren, um sie zu Überwachungszwecken zu verwenden.
Service-Worker-Allowed: Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header in der Antwort des Service-Worker-Skripts enthalten ist.
SourceMap: Verlinkt zu einer Source Map, sodass Debugger durch den Originalquellcode anstelle von generiertem oder transformiertem 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) hochzustufen. Zum Beispiel kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket hochzustufen.
Priority: Bietet einen Hinweis über die Priorität einer bestimmten Ressourcenanfrage auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzuzeigen, oder in einer Antwort, wenn der Server entscheidet, die Anfrage neu zu priorisieren.

Experimentelle Header

Attribution-Reporting-Header

Die Attribution Reporting API ermöglicht es Entwicklern, Conversions zu messen — zum Beispiel, wenn ein Benutzer auf eine in einer Seite eingebettete Anzeige klickt und dann fortfährt, den Artikel auf der Seite des Anbieters zu kaufen — und dann Berichte über diese Conversions abzurufen. Dies geschieht, ohne sich auf Third-Party-Tracking-Cookies zu verlassen, stattdessen verlässt es sich auf verschiedene Header, um Quellen und Auslöser zu registrieren, die darauf hinweisen, dass eine Conversion stattgefunden hat.

Attribution-Reporting-Eligible: Wird verwendet, um anzugeben, dass die Seitenanforderung durch die Registrierung entweder einer Zuweisungsquelle oder eines Auslösers für die Berichterstattung geeignet ist.
Attribution-Reporting-Register-Source: Teil einer Antwort auf eine Anforderung, die einen Attribution-Reporting-Eligible Header enthielt; dies wird verwendet, um eine Zuweisungsquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Teil einer Antwort auf eine Anforderung, die einen Attribution-Reporting-Eligible Header enthielt; dies wird verwendet, um einen Zuweisungsauslöser zu registrieren.

Client-Hinweise

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

Server fordern proaktiv die Client-Hinweis-Header, an denen sie vom Client interessiert sind, indem sie Accept-CH verwenden. 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 über das Accept-CH Header-Feld oder ein entsprechendes HTML <meta> Element mit http-equiv Attribut ankündigen.
Critical-CH: Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client-Hinweise auch kritische Client-Hinweise sind.

Die unterschiedlichen Kategorien von Client-Hinweisen sind unten aufgelistet.

Benutzeragent-Client-Hinweise

Die UA-Client-Hinweise sind Anfrage-Header, die Informationen über den Benutzer-Agent, die Plattform/Architektur, auf der er läuft, und Benutzereinstellungen, die auf dem Benutzer-Agent oder der Plattform gesetzt sind, bereitstellen:

Sec-CH-UA: Benutzeragent-Branding und Version.
Sec-CH-UA-Arch: Benutzeragent-Grundplattformarchitektur.
Sec-CH-UA-Bitness: Benutzeragent-Grund-CPU-Architektur-Bitness (zum Beispiel "64" Bit).
Sec-CH-UA-Form-Factors: Benutzeragent-Formfaktoren, die beschreiben, wie der Benutzer mit dem Benutzer-Agent interagiert.
Sec-CH-UA-Full-Version: Benutzeragent-Vollversionszeichenfolge.
Sec-CH-UA-Full-Version-List: Vollversion für jede Marke in der Markenliste des Benutzer-Agents.
Sec-CH-UA-Mobile: Benutzeragent läuft auf einem mobilen Gerät oder bevorzugt im Allgemeinen eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model: Benutzeragent-Gerätemodell.
Sec-CH-UA-Platform: Benutzeragent-Grundlage bzw. Betriebssystem/Plattform.
Sec-CH-UA-Platform-Version: Benutzeragent-Betriebssystemversion.
Sec-CH-UA-WoW64: Ob der Benutzer-Agent-Binary im 32-Bit-Modus auf 64-Bit-Windows läuft oder nicht.
Sec-CH-Prefers-Color-Scheme: Benutzerpräferenz für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion: Benutzerpräferenz, weniger Animationen und Layoutverschiebungen für Inhalte zu sehen.
Sec-CH-Prefers-Reduced-Transparency: Anfrage-Header, der die Benutzeragent-Präferenz für reduzierte Transparenz angibt.

Hinweis: Benutzeragent-Client-Hinweise sind innerhalb von fenced frames nicht verfügbar, da sie sich auf die Rechte-Policy Delegation stützen, die verwendet werden könnte, um Daten zu leaken.

Geräte- und responsive Bild-Client-Hinweise

Sec-CH-Device-Memory: Ungefährer Betrag des verfügbaren RAM-Speichers des Clients. Dies ist Teil der Device Memory API.
Sec-CH-DPR: Anfrage-Header, der das Geräte-Pixelverhältnis des Clients bereitstellt (die Anzahl der physikalischen Gerätepixel pro CSS-Pixel).
Sec-CH-Viewport-Height: Anfrage-Header, der die Layout-Viewport-Höhe des Clients in CSS-Pixeln bereitstellt.
Sec-CH-Viewport-Width: Anfrage-Header, der die Layout-Viewport-Breite des Clients in CSS-Pixeln bereitstellt.
Sec-CH-Width: Anfrage-Header, der die Bildbreite in CSS-Pixeln bereitstellt.

Veraltete Geräte- und responsive Bild-Client-Hinweise

Device-Memory: Standardisiert als Sec-CH-Device-Memory
DPR: Standardisiert als Sec-CH-DPR
Viewport-Width: Standardisiert als Sec-CH-Viewport-Width
Width: Standardisiert als Sec-CH-Width

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise erlauben es einem Server, zu wählen, welche Informationen basierend auf der Benutzerauswahl und der Netzwerkbandbreite und -latenz gesendet werden.

Downlink: Ungefähre Bandbreite der Client-Verbindung zum Server, in Mbps. Dies ist Teil der Network Information API.
ECT: Der effektive Verbindungstyp ("Netzwerkprofil"), der die Latenz und Bandbreite der Verbindung am besten beschreibt. Dies ist Teil der Network Information API.
RTT: Rundlaufzeit auf Anwendungsebene (RTT) in Millisekunden, die die Serverbearbeitungszeit einschließt. Dies ist Teil der Network Information API.
Save-Data: Ein String on, der die Präferenz des Benutzer-Agents für reduzierten Datenverbrauch angibt.

Kompressionswörterbuch-Transport

Kompressionswörterbuch-Transport ist eine Möglichkeit, ein gemeinsames 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: Ein Browser kann diesen Anfrage-Header verwenden, um das beste Wörterbuch anzugeben, das ihm für den Server zur Verwendung bei der Kompression zur Verfügung steht.
Dictionary-ID: 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 bereitstellt. Anfragen für Ressourcen, die das Wörterbuch verwenden können, verfügen über einen Available-Dictionary Header und die vom Server bereitgestellte Dictionary-ID im Dictionary-ID Header.
Use-As-Dictionary: Listet die Übereinstimmungskriterien auf, für die das Wörterbuch bei zukünftigen Anfragen verwendet werden kann.

Datenschutz

DNT: Anfrage-Header, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Veraltet zugunsten der Global Privacy Control (GPC), die durch den Sec-GPC Header an Server kommuniziert wird und für Clients über navigator.globalPrivacyControl zugänglich ist.
Tk: Antwort-Header, der den Tracking-Status anzeigt, der auf die entsprechende Anfrage angewendet wurde. Wird in Verbindung mit DNT verwendet.
Sec-GPC: Gibt an, ob der Benutzer damit einverstanden ist, dass eine Website oder ein Service ihre persönlichen Informationen an Dritte verkauft oder teilt.

Sicherheit

Origin-Agent-Cluster: Antwort-Header, der verwendet wird, um anzugeben, dass das zugeordnete Document in einem ursprungsbasierten Agenten-Cluster platziert werden sollte. Diese Isolation ermöglicht es Benutzer-Agents, implementationsspezifische Ressourcen für Agenten-Cluster wie Prozesse oder Threads effizienter zuzuweisen.

Server-gesendete Ereignisse

NEL: Definiert einen Mechanismus, der es Entwicklern ermöglicht, eine Netzwerkausfallberichtpolitik zu erklären.

Themen-API

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

Observe-Browsing-Topics: Antwort-Header, der verwendet wird, um Themen von Interesse zu kennzeichnen, die aus der URL der aufrufenden Seite abgeleitet sind, wenn in der Antwort auf eine Anforderung, die durch eine Funktion generiert wurde, die die Topics API ermöglicht.
Sec-Browsing-Topics: Anfrage-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Werbeplattform verwendet werden, um eine personalisierte Anzeige auszuwählen.

Andere

Accept-Signature: Ein Client kann das Accept-Signature Header-Feld senden, um die Absicht anzugeben, von verfügbaren Signaturen zu profitieren und um anzugeben, welche Art von Signaturen er unterstützt.
Early-Data: Gibt an, dass die Anfrage in TLS Early Data übermittelt wurde.
Idempotency-Key: Bietet einen eindeutigen Schlüssel für POST- und PATCH Anfragen, sodass sie idempotent gemacht werden können.
Set-Login: Antwort-Header, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, was bedeutet, ob Benutzer im aktuellen Browser beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM API verwendet.
Signature: Das Signature Header-Feld vermittelt eine Liste von Signaturen für einen Austausch, wobei jede von ihnen mit Informationen darüber versehen ist, wie die Autorität bestimmt und die Signatur aktualisiert werden kann.
Signed-Headers: Das Signed-Headers Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur einbezogen werden sollen.
Speculation-Rules: Bietet eine Liste von URLs, die auf Textressourcen verweisen, die Spekulationsregel JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zu dem Spekulationsregel-Set des Dokuments hinzugefügt.
Sec-Speculation-Tags: Enthält einen oder mehrere Tag-Werte aus den Spekulationsregeln, die zur Spekulation führten, sodass ein Server identifizieren kann, welche Regel(n) eine Spekulation verursacht haben, und diese möglicherweise blockieren.
Supports-Loading-Mode: Wird von einem Navigationstarget gesetzt, um zu verschiedenen risikoreicheren Lademodi zu wechseln. Zum Beispiel erfordert cross-origin, same-site Pre-Rendering einen Supports-Loading-Mode Wert von credentialed-prerender.

Nicht-standardisierte Header

X-Forwarded-For: Identifiziert die ursprünglichen IP-Adressen eines Clients, der sich über einen HTTP-Proxy oder einen Lastenausgleicher mit einem Webserver verbindet.
X-Forwarded-Host: Identifiziert den ursprünglichen Host, den ein Client zum Verbinden mit Ihrem Proxy oder Lastenausgleicher verwendet hat.
X-Forwarded-Proto: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client zum Verbinden mit Ihrem Proxy oder Lastenausgleicher verwendet hat.
X-DNS-Prefetch-Control: Kontrolliert das DNS-Prefetching, eine Funktion, bei der Browser proaktiv die Namensauflösung bei Domänen sowohl für Links durchführen, denen der Benutzer möglicherweise folgen könnte, als auch für URLs von Artikeln im Dokument, einschließlich Bilder, CSS, JavaScript und so weiter.
X-Robots-Tag: Der X-Robots-Tag HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb der Suchmaschinenergebnisse indexiert werden soll. Der Header entspricht den <meta name="robots"> Elementen.

Veraltete Header

Pragma: Implementationsspezifischer Header, der verschiedene Effekte überall entlang der Request-Response-Kette haben kann. Wird für Rückwärtskompatibilität mit HTTP/1.0-Caches verwendet, in denen der Cache-Control Header noch nicht vorhanden ist.
Warning: Allgemeine Warnhinweise über mögliche Probleme.

Siehe auch

Help improve MDN

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

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