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 besteht ein Header aus einem nicht Groß-/Kleinschreibung-sensitiven Namen, gefolgt von einem Doppelpunkt, dann optionalem Leerraum, der ignoriert wird, und schließlich von seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und später werden Header in Kleinbuchstaben angezeigt, wenn sie in den Entwicklertools betrachtet werden (accept: */*), und für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt vorangestellt (: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 entstanden, wenn nicht standardisierte Felder in RFC 6648 standardisiert wurden, veraltet erklärt; weitere sind im IANA HTTP Field Name Registry aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header, einschließlich Informationen über ihren Status.

Header können nach ihrem Kontext gruppiert werden:

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

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

End-to-End-Header: Diese Header müssen an den letzten Empfänger der Nachricht weitergegeben werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenliegende Proxies müssen diese Header unverändert weitergeben und Caches müssen sie speichern.
Hop-by-Hop-Header: Diese Header sind nur für eine einzelne Transport-Ebene Verbindung sinnvoll und dürfen nicht von Proxies weitergegeben 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 verwendet werden soll, um auf eine Ressource zuzugreifen.
Authorization: Enthält die Anmeldedaten, um einen User-Agent bei einem Server zu authentifizieren.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die verwendet werden soll, um auf eine Ressource hinter einem Proxy-Server zuzugreifen.
Proxy-Authorization: Enthält die Anmeldedaten, um einen User-Agent bei einem Proxy-Server zu authentifizieren.

Zwischenspeicherung

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

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 einfacher zu berechnen in manchen Umgebungen. 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, die die Version der Ressource identifiziert. Bedingte Anfragen, die If-Match und If-None-Match verwenden, nutzen diesen Wert, um das Verhalten der Anfrage zu ändern.
If-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.
If-None-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource 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 dann ü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 dann übertragen wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies stellt die Kohärenz eines neuen Fragments eines spezifischen Bereichs mit vorherigen sicher oder ermöglicht ein optimistisches Konsistenzkontrollsystem beim Ändern bestehender Dokumente.
Vary: Bestimmt, wie Anforderungsheader abgeglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue von dem Ursprungsserver anzufordern.

Verbindungsmanagement

Connection: Kontrolliert, ob die Netzwerkverbindung offen bleibt, nachdem die aktuelle Transaktion abgeschlossen ist.
Keep-Alive: Kontrolliert, wie lange eine persistente Verbindung offen bleiben sollte.

Inhaltsverhandlung

Für weitere Details siehe den Artikel über Inhaltsverhandlung.

Accept: Informiert den Server über die Datentypen, die zurückgesendet werden können.
Accept-Encoding: Der Kodierungsalgorithmus, üblicherweise 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 nur ein Hinweis und nicht unbedingt vollständig unter Kontrolle des Nutzers: der Server sollte immer darauf achten, eine explizite Nutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.
Accept-Patch: Ein Anfrageinhaltsverhandlung-Antwortheader, der angibt, welchen Mediatyp der Server in einer PATCH-Anfrage verstehen kann.
Accept-Post: Ein Anfrageinhaltsverhandlung-Antwortheader, der angibt, welchen Mediatyp der Server in einer POST-Anfrage verstehen kann.

Steuerungen

Expect: Zeigt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage ordnungsgemäß zu bearbeiten.
Max-Forwards: Gibt bei Verwendung von TRACE an, wie viele Hops 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 User-Agent.

CORS

Für weitere Informationen siehe die CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage freigegeben werden kann, wenn das Anmeldeinformations-Flag wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header beim Erstellen der tatsächlichen Anfrage verwendet werden dürfen.
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 geteilt werden kann.
Access-Control-Expose-Headers: Gibt an, welche Header als Teil der Antwort offengelegt werden können, indem ihre Namen aufgeführt werden.
Access-Control-Max-Age: Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage zwischengespeichert werden können.
Access-Control-Request-Headers: Wird beim Erstellen einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die tatsächliche Anfrage erstellt wird.
Access-Control-Request-Method: Wird beim Erstellen einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode verwendet wird, wenn die tatsächliche Anfrage erstellt wird.
Origin: Gibt an, von wo aus ein Fetch stammt.
Timing-Allow-Origin: Gibt Ursprünge an, die die Werte von Attributen sehen dürfen, die über Funktionen der Resource Timing API abgerufen werden, die sonst 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 Header) oder ob sie wie ein Download behandelt werden soll und der Browser ein "Speichern unter"-Dialog anzeigen soll.

Integritätsprüfsummen

Content-Digest: Bietet eine Prüfsumme des Byte-Stroms, der in einer HTTP-Nachricht gerahmt ist (der Nachrichteninhalt), abhängig von Content-Encoding und Content-Range.
Repr-Digest: Bietet eine Prüfsumme der ausgewählten Darstellung der Zielressource vor der Übertragung. Im Gegensatz zum Content-Digest betrachtet die Prüfsumme Content-Encoding oder Content-Range nicht.
Want-Content-Digest: Gibt den Wunsch nach einem Content-Digest-Header an. Es ist das Content- Gegenstück zu Want-Repr-Digest.
Want-Repr-Digest: Gibt den Wunsch nach einem Repr-Digest-Header an. Es ist das Repr- Gegenstück zu Want-Content-Digest.

Integritätspolitik

Integrity-Policy: Stellt sicher, dass alle vom User-Agent geladenen Ressourcen (eines bestimmten Typs) Subresource Integrity Garantien haben.
Integrity-Policy-Report-Only: Berichtet über Ressourcen, die vom User-Agent geladen werden, die gegen Subresource Integrity Garantien verstoßen würden, wenn die Integritätspolitik durchgesetzt würde (unter Verwendung des Integrity-Policy-Headers).

Informationen zum Nachrichtenkörper

Content-Length: Die Größe der Ressource in Dezimalzahl von Bytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Wird verwendet, um den Kompressionsalgorithmus anzugeben.
Content-Language: Beschreibt die beabsichtigten menschlichen Sprachen für das Publikum, sodass ein Benutzer nach eigener bevorzugter Sprache differenzieren kann.
Content-Location: Gibt einen alternativen Standort für die zurückgegebenen Daten an.

Nachrichtensignaturen

Accept-Signature: Der Accept-Signature Header fordert eine signierte Antwort oder nachfolgende Anfrage an, wobei die zu signierenden Komponenten und Signaturparameter spezifiziert werden.
Signature: Der Signature Header enthält einen oder mehrere gelabelte Signaturwerte. Jedes Label entspricht einem Eintrag in Signature-Input.
Signature-Input: Der Signature-Input Header identifiziert die geordnete Liste von Nachrichtenkomponenten, die von jeder Signatur und ihren Metadaten abgedeckt werden, wie z.B. die Erstellungszeit und der Schlüsselidentifikator.

Hinweis: Diese Definitionen folgen RFC 9421. Der Signed HTTP Exchanges (SXG) Entwurf definiert auch Accept-Signature und Signature mit inkompatibler Semantik, plus einem eigenen Signed-Headers Header. Allerdings unterstützt die einzige Browser-SXG-Implementierung, Chromium, diese nicht als HTTP-Header.

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

Prefer: Gibt Präferenzen für spezifische Serververhaltensweisen während der Anfragenverarbeitung an. Zum Beispiel könnte es minimalen Antwortinhalt (return=minimal) oder asynchrone Verarbeitung (respond-async) anfordern. Der Server verarbeitet die Anfrage normal, wenn der Header nicht unterstützt wird.
Preference-Applied: Informiert den Client, welche Präferenzen, die im Prefer-Header angegeben sind, vom Server angewendet wurden. Es ist ein reiner Antwort-Header, der Transparenz bezüglich der Präferenzbehandlung bietet.

Proxies

Forwarded: Enthält Informationen von der clientseitigen Seite von Proxy-Servern, die geändert oder verloren gehen, wenn ein Proxy im Pfad der Anfrage beteiligt ist.
Via: Hinzugefügt von Proxies, sowohl Vorwärts- als auch Rückwärtsproxies, und kann sowohl in den Anforderungsheadern als auch in den Antwortheadern erscheinen.

Bereichsanfragen

HTTP Bereichsanfragen erlauben es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Mediaplayer, die zufälligen Zugriff unterstützen, Datentools, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Download-Manager, die es dem Benutzer ermöglichen, 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ücksenden soll.
If-Range: Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn das angegebene ETag oder Datum mit der entfernten Ressource übereinstimmt. 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 Teilnachricht gehört.

Weiterleitungen

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

Anforderungskontext

From: Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden User-Agent steuert.
Host: Gibt den Domänennamen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server horcht.
Referer: Die Adresse der vorherigen Webseite, von der ein Link zur aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy: Bestimmt, welche Verweisinformationen, die im Referer-Header gesendet werden, in Anfragen enthalten sein sollten.
User-Agent: Enthält eine charakteristische Zeichenkette, die den Netzwerkprotokoll-Peers ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwarehersteller oder die Softwareversion des anfordernden Software-User-Agents 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 bearbeiten.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht einem Server, eine Embedding-Politik 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 der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch CORP-Erklärungsartikel.
Content-Security-Policy (CSP): Kontrolliert, welche Ressourcen der User-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Ermöglicht Webentwicklern, mit Richtlinien zu experimentieren, indem sie ihre Auswirkungen überwachen, aber nicht durchsetzen. Diese Verletzungsberichte bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.
Expect-CT: Ermöglicht es Seiten, Berichterstattung und Durchsetzung von Certificate Transparency zu melden, um den Einsatz falsch ausgestellter Zertifikate für diese Seite zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Nutzung von Browserfunktionen im eigenen Rahmen einer Website und in <iframe>s, die sie einbettet, zu erlauben und zu verweigern.
Reporting-Endpoints: Antwortheader, der es Website-Betreibern ermöglicht, einen oder mehrere Endpunkte anzugeben, die verwendet werden, um Fehler wie CSP-Verletzungsberichte, Cross-Origin-Opener-Policy-Berichte oder andere allgemeine 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, das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt und angibt, dass er die upgrade-insecure-requests-Richtlinie erfolgreich handhaben kann.
X-Content-Type-Options: Deaktiviert das MIME-Sniffing und zwingt den Browser, den im Content-Type-Header angegebenen Typ zu verwenden.
X-Frame-Options (XFO): Gibt an, ob ein Browser erlauben sollte, eine Seite in einem <frame>, <iframe>, <embed> oder <object> anzuzeigen.
X-Permitted-Cross-Domain-Policies: Eine Cross-Domain-Richtliniendatei kann Clients, wie Adobe Acrobat oder Apache Flex (unter anderen), die Erlaubnis erteilen, Daten über Domains hinweg zu handhaben, die sonst aufgrund der Same-Origin-Policy 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, während sie keinen Nutzen für die Anwendung oder ihre Besucher bieten. Entfernen Sie diesen Header, um das Offenlegen potenzieller Schwachstellen zu vermeiden.
X-XSS-Protection: Aktiviert die Filterung von Cross-Site Scripting.

Fetch-Metadaten-Anforderungsheader

Fetch-Metadaten-Anforderungsheader liefern Informationen über den Kontext, aus dem die Anfrage stammt. Ein Server kann sie nutzen, um Entscheidungen zu treffen, ob eine Anfrage erlaubt werden sollte, basierend darauf, woher die Anfrage stammt und wie die Ressource genutzt wird.

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprung des Anforderungsinitiators und dem Zielursprung an. Es ist ein strukturiertes 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 strukturiertes 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 strukturiertes Header, dessen Wert ein Boolescher Wert ist, sodass die möglichen Werte ?0 für falsch und ?1 für wahr sind.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es ist ein strukturiertes 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-Metadaten-Anforderungsheader", liefern aber ähnlich Informationen über den Kontext, wie eine Ressource verwendet wird. Ein Server könnte sie nutzen, um sein Zwischenspeicherverhalten zu ändern oder die zurückgegebenen Informationen:

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

Fetch-Speicherzugriffsheader

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

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

Servergesendete Ereignisse

Reporting-Endpoints: Antwortheader, der zur Angabe von Serverendpunkten verwendet wird, wohin der Browser beim Verwenden der Reporting API Warn- und Fehlerberichte senden soll.
Report-To: Antwortheader, der zur Angabe von Serverendpunkten verwendet wird, wohin der Browser beim Verwenden der Reporting API Warn- und Fehlerberichte senden soll.

Transferkodierung

Transfer-Encoding: Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.
TE: Gibt die Transferkodierungen an, die der User-Agent akzeptieren möchte.
Trailer: Ermöglicht es dem Sender, zusätzliche Felder am Ende einer chunked-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, auf eine WebSocket-Verbindung umzusteigen.
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 ausgewählte Erweiterung aus den Präferenzen des Clients an.
Sec-WebSocket-Key: Anforderungsheader, der einen Schlüssel enthält, der verifiziert, dass der Client explizit beabsichtigt, einen WebSocket zu öffnen.
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 ausgewählte Subprotokoll aus den Präferenzen des Clients 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 zu listen, 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äts-Header-Feld bietet eine Möglichkeit, eine oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML <link>-Element.
Retry-After: Gibt an, wie lange der User-Agent warten sollte, bevor eine Folgeanfrage durchgeführt wird.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfragen-Antwort-Zyklus.
Service-Worker: Enthalten in Abrufen für die Skriptressource eines Service Workers. Dieser Header hilft Administratoren, Anfragen von Service-Worker-Skripten zu protokollieren, um Überwachungszwecke zu erfüllen.
Service-Worker-Allowed: Wird verwendet, um die Pfadbeschränkung aufzuheben, indem dieser Header in der Antwort des Service Worker-Skripts enthalten ist.
SourceMap: Links zu einer Quellkarte, damit Debugger durch den originalen Quellcode anstelle von generiertem oder transformiertem Code gehen 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) umzurüsten. 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 aufzurüsten.
Priority: Bietet einen Hinweis auf die Priorität einer bestimmten Ressourcenanfrage auf einer bestimmten Verbindung. Der Wert kann in einer Anfrage gesendet werden, um die Client-Priorität anzugeben, oder in einer Antwort, wenn der Server wählt, die Anfrage neu zu priorisieren.

Experimentelle Header

Attributions-Reporting-Header

Die Attributions-Reporting-API ermöglicht es Entwicklern, Konversionen zu messen — zum Beispiel, wenn ein Benutzer auf eine eingebettete Anzeige auf einer Seite klickt und dann den Artikel auf der Website des Anbieters kauft — und dann auf Berichte über diese Konversionen zuzugreifen. Dies wird ohne den Einsatz von Drittanbieter-Tracking-Cookies erreicht, sondern setzt auf verschiedene Header, um Quellen und Trigger zu registrieren, die auf eine Konversion hinweisen.

Attribution-Reporting-Eligible: Wird verwendet, um anzugeben, dass die Antwort, die der aktuellen Anfrage entspricht, berechtigt ist, am Attribution-Reporting teilzunehmen, indem entweder eine Quell- oder Trigger-Attribution registriert wird.
Attribution-Reporting-Register-Source: Ist Bestandteil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt. Diese wird verwendet, um eine Quellen-Attribution zu registrieren.
Attribution-Reporting-Register-Trigger: Ist Bestandteil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible-Header enthielt. Diese wird verwendet, um einen Trigger für die Attribution zu registrieren.

Client-Hinweise

HTTP-Client-Hinweise sind eine Reihe von Anforderungsheadern, die nützliche Informationen über den Client wie Gerätetyp und Netzwerkbedingungen liefern und es Servern erlauben, das, was für diese Bedingungen serviert wird, zu optimieren.

Server fordern proaktiv die Client-Hinweisheader an, an denen sie interessiert sind, indem sie Accept-CH verwenden. Der Client kann sich dann entscheiden, die angeforderten Header in nachfolgenden Anfragen zu enthalten.

Accept-CH: Server können Unterstützung für Client-Hinweise über das Accept-CH-Header-Feld oder ein entsprechendes HTML-<meta>-Element mit dem http-equiv Attribut anzeigen.
Critical-CH: Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client-Hinweise auch kritische Client-Hinweise sind.

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

User-Agent-Client-Hinweise

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

Sec-CH-UA: Markenname und Version des User-Agents.
Sec-CH-UA-Arch: Unterliegende Plattformarchitektur des User-Agents.
Sec-CH-UA-Bitness: Bitness der zugrunde liegenden CPU-Architektur des User-Agents (z.B. "64" bit).
Sec-CH-UA-Form-Factors: Formfaktoren des User-Agents, die beschreiben, wie der Benutzer mit dem User-Agent interagiert.
Sec-CH-UA-Full-Version: Vollständiger Versionsstring des User-Agents.
Sec-CH-UA-Full-Version-List: Vollständige Version für jede Marke in der Markenliste des User-Agents.
Sec-CH-UA-Mobile: User-Agent läuft auf einem mobilen Gerät oder bevorzugt allgemein eine "mobile" Benutzererfahrung mehr.
Sec-CH-UA-Model: Gerätemodell des User-Agents.
Sec-CH-UA-Platform: Betriebssystem/Plattform des User-Agents.
Sec-CH-UA-Platform-Version: Version des Betriebssystems/der Plattform des User-Agents.
Sec-CH-UA-WoW64: Ob der User-Agent-Binär im 32-Bit-Modus auf 64-Bit-Windows läuft oder nicht.
Sec-CH-Prefers-Color-Scheme: Vorliebe des Benutzers für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion: Vorliebe des Benutzers, weniger Animationen und Layoutänderungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency: Anforderungsheader, der die Vorliebe des Benutzer-Agents für reduzierte Transparenz anzeigt.

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

Geräte- und anpassbare Bild-Client-Hinweise

Sec-CH-Device-Memory: Ungefähre Menge an verfügbarem RAM-Speicher des Clients. Dies ist Teil der Device Memory API.
Sec-CH-DPR: Anforderungsheader, der das Geräte-Pixel-Verhältnis des Clientgeräts bereitstellt (die Anzahl der physischen Geräte-Pixel pro CSS-Pixel).
Sec-CH-Viewport-Height: Anforderungsheader, der die Layout-Viewport-Höhe des Clients in CSS-Pixeln bereitstellt.
Sec-CH-Viewport-Width: Anforderungsheader, der die Layout-Viewport-Breite des Clients in CSS-Pixeln bereitstellt.
Sec-CH-Width: Anforderungsheader, der die Breite des Bildes in CSS-Pixeln bereitstellt.

Veraltete Geräte- und anpassbare 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 einem Server zu wählen, welche Informationen basierend auf der Benutzerwahl und der Netzwerkbandbreite und Latenz gesendet werden.

Downlink: Ungefähre Bandbreite der Verbindung des Clients zum Server in Mbit/s. Dies ist Teil der Netzwerk-Informationen-API.
ECT: Der effektive Verbindungstyp ("Netzwerkprofil"), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Netzwerk-Informationen-API.
RTT: Round-Trip-Zeit auf der Anwendungsschicht (RTT) in Millisekunden, die die Serververarbeitungszeit enthält. Dies ist Teil der Netzwerk-Informationen-API.
Save-Data: Eine Zeichenkette on, die die Vorliebe des Benutzer-Agents für eine reduzierte Datennutzung anzeigt.

Kompressionswörterbuchübertragung

Kompressionswörterbuchübertragung ist eine Möglichkeit, ein gemeinsames Kompressionswörterbuch zu verwenden, um die Transportgröße von HTTP-Antworten zu reduzieren, anstatt das Standardstatik-Wörterbuch in Brotli-Kompression oder Zstandard-Kompression zu verwenden.

Available-Dictionary: Ein Browser kann diesen Anforderungsheader verwenden, um das beste verfügbare Wörterbuch anzugeben, das der Server für die Kompression verwenden kann.
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 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: Listet die Abstimmungskriterien auf, für die das Wörterbuch bei zukünftigen Anfragen verwendet werden kann.

Datenschutz

DNT: Anforderungsheader, der die Tracking-Präferenz des Benutzers angibt (Do Not Track). Veraltet zugunsten von Global Privacy Control (GPC), das an Server mithilfe des Sec-GPC Headers übermittelt wird und von Clients über navigator.globalPrivacyControl verwendet wird.
Tk: Antwortheader, der den Tracking-Status angibt, der auf die entsprechende Anfrage angewendet wurde. Wird in Verbindung mit DNT verwendet.
Sec-GPC: Gibt an, ob der Benutzer zustimmt, dass eine Website oder ein Dienst seine persönlichen Informationen an Dritte verkauft oder teilt.

Sicherheit

Origin-Agent-Cluster: Antwortheader wird verwendet, um anzugeben, dass das zugehörige Document in einen ursprungsbezogenen Agent-Cluster platziert werden sollte. Diese Isolierung ermöglicht es Benutzer-Agents, implementierungsspezifische Ressourcen effizienter für Agent-Cluster zuzuweisen, wie z.B. Prozesse oder Threads.

Servergesendete Ereignisse

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

Topics API

Die Topics API bietet einen Mechanismus für Entwickler, Anwendungsfälle wie interessenbezogene Werbung umzusetzen. Siehe die Topics API Dokumentation für weitere Informationen.

Observe-Browsing-Topics: Antwortheader, der verwendet wird, um Themen von Interesse zu markieren, die aus der URL der aufrufenden Website als beobachtet in der Antwort auf eine Anfrage markiert werden, die von einer Funktion generiert wurde, die die Topics API aktiviert.
Sec-Browsing-Topics: Anforderungsheader, der die für den aktuellen Benutzer ausgewählten Themen zusammen mit der zugehörigen Anfrage versendet, die von einer AdTech-Plattform verwendet werden, um eine personalisierte Werbung auszuwählen, die angezeigt werden soll.

Andere

Early-Data: Gibt an, dass die Anfrage im TLS-Early-Data übermittelt wurde.
Idempotency-Key: Bietet einen einzigartigen Schlüssel für POST und PATCH-Anfragen, wodurch sie idempotent gemacht werden können.
Set-Login: Antwortheader, der von einem föderierten Identity-Provider (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, d.h. ob Benutzer im aktuellen Browser beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM API verwendet.
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 zum Spekulationsregelet des Dokuments hinzugefügt.
Sec-Speculation-Tags: Enthält einen oder mehrere Tag-Werte aus den Spekulationsregeln, die zur Spekulation geführt haben, sodass ein Server identifizieren kann, welche Regel(n) eine Spekulation verursacht haben und sie gegebenenfalls blockieren können.
Supports-Loading-Mode: Setzt ein Navigationsziel, um sich für die Verwendung verschiedener riskanterer Lademodi zu entscheiden. Zum Beispiel erfordert Cross-Origin, Same-Site Prerendering einen Supports-Loading-Mode Wert von credentialed-prerender.

Nicht standardisierte Header

X-Forwarded-For: Identifiziert die ursprüngliche IP-Adresse eines Clients, der sich über einen HTTP-Proxy oder einen Load Balancer mit einem Webserver verbindet.
X-Forwarded-Host: Identifiziert den ursprünglichen Host, der angefordert wurde, den ein Client verwendet hat, um sich mit dem Proxy oder Load Balancer zu verbinden.
X-Forwarded-Proto: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um sich mit dem Proxy oder Load Balancer zu verbinden.
X-DNS-Prefetch-Control: Steuerung des DNS-Prefetching, einer Funktion, bei der Browser die Domainnamenauflösung sowohl für Links, die der Benutzer möglicherweise folgen wird, als auch für URLs von Elementen, auf die das Dokument verweist, proaktiv ausführen, einschließlich Bildern, CSS, JavaScript usw.
X-Robots-Tag: Der X-Robots-Tag HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb öffentlicher Suchmaschinenergebnisse indexiert werden soll. Der Header ist äquivalent zu <meta name="robots"> Elementen.

Veraltete Header

Pragma: Implementierungsspezifischer Header, der überall entlang der Request-Response-Kette verschiedene Auswirkungen haben kann. Wird zur Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, in denen der Cache-Control-Header noch nicht vorhanden ist.
Warning: Allgemeine Warninformationen ü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