HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anfrage oder Antwort zu übermitteln. In HTTP/1.X ist ein Header ein nicht auf Groß- und Kleinschreibung achtender Name, gefolgt von einem Doppelpunkt, dann einem optionalen 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 für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt versehen (:status: 200). Weitere Informationen zur Syntax in den einzelnen Protokollversionen finden Sie auf der Seite HTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden historisch mit einem X- Präfix verwendet, aber diese Konvention wurde 2012 in RFC 6648 aufgehoben, da sie Unannehmlichkeiten verursachte, wenn nicht standardisierte Felder 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 ihren Status.

Header können entsprechend ihren Kontexten gruppiert werden:

Anfrage-Header: Enthalten zusätzliche Informationen über die abzurufende Ressource oder den Client, der die Ressource anfordert.
Antwort-Header: Enthalten zusätzliche Informationen über die Antwort, wie deren Standort oder über 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.
Payload-Header: Enthalten darstellungsunabhängige Informationen über die Payload-Daten, einschließlich der Inhaltslänge und der zur Übertragung verwendeten Kodierung.

Header können auch nach der Art und Weise gruppiert werden, wie Proxys sie handhaben:

End-to-end-Header: Diese Header müssen an den endgültigen Empfänger der Nachricht übertragen werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischenliegende Proxys 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 sinnvoll und dürfen nicht von Proxys weitergeleitet oder zwischenspeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mit dem Connection Header gesetzt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource zuzugreifen.
Authorization: Enthält die Anmeldedaten, um einen Benutzer-Agent beim Server zu authentifizieren.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource hinter einem Proxy-Server zuzugreifen.
Proxy-Authorization: Enthält die Anmeldedaten, um einen Benutzer-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 Cache-Mechanismen in sowohl Anfragen als auch Antworten.
Clear-Site-Data: Löscht Browsing-Daten (z.B. Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind.
Expires: Das Datum/die Uhrzeit, nach der die Antwort als veraltet angesehen 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 Einträge im Browser-Cache gespeichert werden sollte.

Bedingte Anfragen

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 manchen Umgebungen leichter zu berechnen. Bedingte Anfragen mit If-Modified-Since und If-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anfrage zu ändern.
ETag: Eine eindeutige Zeichenkette zur Identifizierung der Version der Ressource. 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 mit keinem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen) oder um zu verhindern, dass eine neue Ressource hochgeladen wird, wenn bereits eine existiert.
If-Modified-Since: Macht die Anfrage bedingt und erwartet, dass die Ressource nur übermittelt 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 übermittelt wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies stellt die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen sicher oder implementiert ein optimistisches Sperrverwaltungssystem bei der Änderung bestehender Dokumente.
Vary: Bestimmt, wie Anforderungs-Header abgeglichen werden sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.

Verbindungsverwaltung

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.

Inhaltsaushandlung

Für weitere Einzelheiten schauen Sie sich den Artikel über Inhaltsaushandlung an.

Accept: Informiert den Server darüber, welche Typen von Daten zurückgesendet werden können.
Accept-Encoding: Der Kodierungsalgorithmus, normalerweise 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 in der Kontrolle des Benutzers: der Server sollte immer darauf achten, eine explizite Benutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown) 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.

Steuerungen

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 an, wie viele Hops die Anfrage machen kann, bevor sie an den Sender 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 hierzu finden Sie in der CORS-Dokumentation.

Access-Control-Allow-Credentials: Gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn die Anmeldeinformationskennung wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header verwendet werden können, wenn die tatsächliche Anfrage gestellt wird.
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 aufgelistet werden.
Access-Control-Max-Age: Gibt an, wie lange die Ergebnisse einer Preflight-Anfrage zwischengespeichert werden können.
Access-Control-Request-Headers: Wird beim Ausstellen einer Preflight-Anfrage verwendet, um den Server darauf hinzuweisen, welche HTTP-Header verwendet werden, wenn die tatsächliche Anfrage gestellt wird.
Access-Control-Request-Method: Wird beim Ausstellen einer Preflight-Anfrage verwendet, um den Server darauf hinzuweisen, welche HTTP-Methode verwendet wird, wenn die tatsächliche Anfrage gestellt wird.
Origin: Gibt an, von woher ein Abruf stammt.
Timing-Allow-Origin: Gibt an, welche Ursprünge 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 gemeldet 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 einen "Speichern unter"-Dialog präsentieren soll.

Integritätsdigests

Content-Digest Experimentell: Stellt einen Digest des Stream von Oktetten bereit, die in einer HTTP-Nachricht (dem Nachrichtengehalt) gerahmt sind, abhängig von Content-Encoding und Content-Range.
Repr-Digest Experimentell: Stellt einen Digest der ausgewählten Repräsentation der Zielressource vor der Übertragung bereit. Anders als der Content-Digest berücksichtigt der Digest weder Content-Encoding noch Content-Range.
Want-Content-Digest Experimentell: Gibt den Wunsch nach einem Content-Digest-Header an. Es ist das Content- Analogon zu Want-Repr-Digest.
Want-Repr-Digest Experimentell: Gibt den Wunsch nach einem Repr-Digest-Header an. Es ist das Repr- Analogon zu Want-Content-Digest.

Integritätspolice

Integrity-Policy: Stellt sicher, dass alle vom Benutzeragenten geladene Ressourcen (eines bestimmten Typs) Subresource Integrity Zusicherungen haben.
Integrity-Policy-Report-Only: Berichtet über Ressourcen, die der Benutzeragent lädt, die gegen Subresource Integrity Zusicherungen verstoßen würden, wenn die Integritätspolitik durchgesetzt würde (unter Verwendung des Integrity-Policy Headers).

Informationen zum Nachrichtentext

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 für das Publikum beabsichtigte menschliche Sprache(n), sodass sie einem Benutzer ermöglicht, je nach den bevorzugten Sprachen der Benutzer zu unterscheiden.
Content-Location: Gibt einen alternativen Ort 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 wurde, in Fällen, in denen es sonst für den Client zweideutig wäre. Browser haben keine native Unterstützung für das Senden von Präferenzen über diese Header; sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.

Prefer: Gibt Präferenzen für bestimmte Serververhalten während der Anfrageverarbeitung an. Beispielsweise kann es minimalen Antwortinhalt anfordern (return=minimal) oder asynchrone Verarbeitung (respond-async). Der Server verarbeitet die Anfrage normalerweise, 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 über die Präferenzbehandlung bietet.

Proxys

Forwarded: Enthält Informationen von der Client-seitigen Proxy-Serverseite, die geändert oder verloren gegangen sind, wenn ein Proxy im Pfad der Anfrage beteiligt ist.
Via: Wird von Proxys hinzugefügt, sowohl Forward- als auch Reverse-Proxys, und kann in den Anforderungs- und Antwortheadern erscheinen.

Bereichsanfragen

HTTP-Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Mediaplayer, die zufälligen Zugriff unterstützen, Datentools, die wissen, dass sie nur einen Teil einer großen Datei benötigen, und Download-Manager, die dem Benutzer das Anhalten und Fortsetzen eines Downloads ermöglichen.

Accept-Ranges: Gibt an, ob der Server Bereichsanfragen unterstützt und, falls ja, in welcher Einheit der Bereich ausgedrückt werden kann.
Range: Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.
If-Range: Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn das angegebene ETag oder Datum mit der Remote-Ressource übereinstimmt. Wird verwendet, um zu verhindern, dass zwei Bereiche von einer inkompatiblen Version der Ressource heruntergeladen werden.
Content-Range: Gibt an, wo in einer vollständigen Nachricht ein Teil der Nachricht hingehört.

Weiterleitungen

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

Anforderungskontext

From: Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden Benutzeragenten kontrolliert.
Host: Gibt den Domainnamen des Servers (für das virtuelle Hosting) und (optional) die TCP-Portnummer an, über die der Server lauscht.
Referer: Die Adresse der vorherigen Webseite, von der aus ein Link zur derzeit angeforderten Seite gefolgt wurde.
Referrer-Policy: Bestimmt, welche Verweiserinformationen, die im Referer-Header gesendet werden, in Anfragen enthalten sein 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 anfragenden Software-Benutzeragenten zu identifizieren.

Antwortkontext

Allow: Listen die Menge der von einer Ressource unterstützten HTTP-Anforderungsmethoden auf.
Server: Enthält Informationen über die Software, die vom Ursprungsserver verwendet wurde, um die Anfrage zu bearbeiten.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht einem Server, eine Einbettungsrichtlinie für ein bestimmtes Dokument festzulegen.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domains ein Fenster öffnen/kontrollieren.
Cross-Origin-Resource-Policy (CORP): Verhindert, dass andere Domains auf die Antwort der Ressourcen zugreifen, auf die dieser Header angewendet wird. Siehe auch den CORP-Erklärungsartikel.
Content-Security-Policy (CSP): Kontrolliert Ressourcen, die der Benutzeragent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Ermöglicht Webentwicklern, mit Richtlinien zu experimentieren, indem ihre Effekte überwacht, aber nicht erzwungen werden. Diese Verstoßmeldungen bestehen aus JSON-Dokumenten, die über eine HTTP-POST-Anforderung an die angegebene URI gesendet werden.
Expect-CT Veraltet: Ermöglicht es Websites, sich für das Reporting und die Durchsetzung von Certificate Transparency zu entscheiden, um die Verwendung von falsch ausgestellten Zertifikaten für diese Website zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Nutzung von Browserfunktionen in einem eigenen Frame einer Website und in <iframe>s, die sie einbettet, zu erlauben und zu verweigern.
Reporting-Endpoints Experimentell: Antwort-Header, der es Website-Besitzern ermöglicht, einen oder mehrere Endpunkte anzugeben, 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): 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 dass er erfolgreich die upgrade-insecure-requests-Richtlinie handhaben kann.
X-Content-Type-Options: Deaktiviert 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 plattformübergreifende Richtlinien-Datei kann Clients, wie Adobe Acrobat oder Apache Flex (unter anderem), die Berechtigung gewähren, Daten über Domains hinweg zu verarbeiten, die ansonsten aufgrund der Same-Origin Policy eingeschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients immer noch unerwünschte Anfragen blockieren.
X-Powered-By: Kann von Hosting-Umgebungen oder anderen Frameworks festgelegt werden und enthält Informationen über diese, bietet jedoch keinen Nutzen für die Anwendung oder ihre Besucher. Entfernen Sie diesen Header, um potenzielle Sicherheitslücken 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 verwenden, um darüber zu entscheiden, ob eine Anfrage basierend auf ihrer Herkunft und der Art und Weise, wie die Ressource verwendet wird, erlaubt werden soll.

Sec-Fetch-Site: Gibt das Verhältnis zwischen dem Ursprung des Anforderungsinitiators und dem Zielursprung an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token ist, das mögliche Werte wie cross-site, same-origin, same-site und none hat.
Sec-Fetch-Mode: Gibt den Modus der Anfrage an einen Server an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token ist, das mögliche Werte wie cors, navigate, no-cors, same-origin und websocket hat.
Sec-Fetch-User: Gibt an, ob eine Navigationsanfrage durch eine Nutzeraktivierung ausgelöst wurde oder nicht. Es handelt sich um einen strukturierten Header, dessen Wert ein boolescher Wert ist, sodass mögliche Werte ?0 für falsch und ?1 für wahr sind.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token ist, das mögliche Werte wie audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker und xslt hat.

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 verwenden, um sein Cache-Verhalten zu ändern oder die zurückgegebenen Informationen zu modifizieren:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn dieser 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 präventiv für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungsheader, der in einer präventiven Anfrage zu fetch() einer Ressource während des Startvorgangs eines Service Workers gesendet wird. Der Wert, der mit NavigationPreloadManager.setHeaderValue() gesetzt wird, kann verwendet werden, um einen Server darüber zu informieren, dass eine andere Ressource zurückgegeben werden sollte als in einer normalen fetch()-Operation.

Fetch-Speicherzugriff-Header

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

Sec-Fetch-Storage-Access: Gibt den "Speicherzugriffsstatus" für den aktuellen Fetch-Kontext an, der einer von none, inactive oder active sein wird. Der Server kann mit Activate-Storage-Access antworten, um den Browser darum zu bitten, eine inactive-Berechtigung zu aktivieren und die Anfrage erneut zu versuchen, oder eine Ressource mit Zugriff auf ihre Drittanbieter-Cookies zu laden, wenn der Status active ist.
Activate-Storage-Access: Wird als 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 kann, oder eine Ressource mit Cookie-Zugriff laden kann, wenn bereits eine aktivierte Berechtigung vorhanden ist.

Vom Server gesendete Ereignisse

Reporting-Endpoints: Antwort-Header, der verwendet wird, um Server-Endpunkte anzugeben, an die der Browser Warn- und Fehlermeldungen beim Verwenden der Reporting API senden soll.
Report-To Veraltet Nicht standardisiert: Antwort-Header, der verwendet wird, um Server-Endpunkte anzugeben, an die der Browser Warn- und Fehlermeldungen beim Verwenden der Reporting API senden soll.

Transfer-Codierung

Transfer-Encoding: Gibt die Form der Kodierung an, die verwendet wird, um die Ressource sicher an den Benutzer zu übertragen.
TE: Gibt die Transferkodierungen an, die der Benutzeragent zu akzeptieren bereit ist.
Trailer: Ermöglicht 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: Antwort-Header, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung zu aktualisieren.
Sec-WebSocket-Extensions: In Anfragen gibt dieser Header die vom Client unterstützten WebSocket-Erweiterungen in bevorzugter Reihenfolge an. In Antworten gibt er die vom Server aus den Präferenzen des Clients ausgewählte Erweiterung an.
Sec-WebSocket-Key: Anforderungs-Header, der einen Schlüssel enthält, der überprüft, dass der Client ausdrücklich die Absicht hat, einen WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die vom Client unterstützten Sub-Protokolle in bevorzugter Reihenfolge an. In Antworten gibt er das vom Server aus den Präferenzen des Clients ausgewählte Sub-Protokoll an.
Sec-WebSocket-Version: In Anfragen gibt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn die angeforderte Protokollversion vom Server nicht unterstützt wird, und listet die vom Server unterstützten Versionen auf.

Sonstiges

Alt-Svc: Wird verwendet, um alternative Möglichkeiten aufzulisten, diesen Service zu erreichen.
Alt-Used: Wird verwendet, um den genutzten alternativen 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 zur Serialisierung von einem oder mehreren Links in HTTP-Headern. Es ist semantisch äquivalent zum HTML <link> Element.
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 Anforderungs-Antwort-Zyklus.
Service-Worker: Wird in Fetches für eine Ressource des Service Workers eingebunden. Dieser Header hilft Administratoren, Service Worker-Skriptanfragen zu protokollieren, um Überwachungszwecke zu erfüllen.
Service-Worker-Allowed: Wird verwendet, um die Pfadeinschränkung zu entfernen, indem dieser Header in der Antwort des Service Worker-Skripts einbezogen wird.
SourceMap: Verlinkt auf eine Source Map, sodass 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 auf ein anderes Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Beispielsweise kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 auf HTTP 2.0 zu aktualisieren oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket umzuwandeln.
Priority: Gibt einen Hinweis auf die Priorität einer bestimmten Ressourcenanforderung auf einer bestimmten Verbindung. Der Wert kann in einer Anforderung gesendet werden, um die Client-Priorität anzugeben, oder in einer Antwort, falls der Server beschließt, die Anforderung zu repriorisieren.

Experimentelle Header

Attribution Reporting-Header

Die Attribution Reporting API ermöglicht es Entwicklern, Conversions zu messen — zum Beispiel, wenn ein Benutzer auf eine auf einer Seite eingebettete Anzeige klickt und dann das Produkt auf der Seite des Anbieters kauft — und dann Berichte über diese Conversions abzurufen. Dies geschieht ohne den Einsatz von Third-Party-Tracking-Cookies, sondern durch die Verwendung verschiedener Header, um Quellen und Trigger zu registrieren, die übereinstimmen, um eine Conversion anzuzeigen.

Attribution-Reporting-Eligible: Wird verwendet, um anzuzeigen, dass die Antwort zur aktuellen Anfrage berechtigt ist, an der Attribution-Berichterstattung teilzunehmen, indem entweder eine Attribution-Quelle oder ein Trigger registriert wird.
Attribution-Reporting-Register-Source: Wird als Teil einer Antwort auf eine Anfrage eingefügt, die einen Attribution-Reporting-Eligible-Header enthielt, wird dies verwendet, um eine Attribution-Quelle zu registrieren.
Attribution-Reporting-Register-Trigger: Wird als Teil einer Antwort auf eine Anfrage eingefügt, die einen Attribution-Reporting-Eligible-Header enthielt, wird dies verwendet, um einen Attribution-Trigger zu registrieren.

Client Hints

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

Server fordern proaktiv die Client-Hint-Header an, an denen sie interessiert sind, vom Client an, indem sie Accept-CH verwenden. Der Client kann dann entscheiden, die angeforderten Header in nachfolgenden Anfragen einzufügen.

Accept-CH: Server können die Unterstützung für Client Hints mithilfe des Accept-CH Header-Felds oder eines äquivalenten HTML-<meta>-Elements mit dem http-equiv-Attribut bewerben.
Critical-CH Experimentell: Server verwenden Critical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client Hints ebenfalls kritische Client Hints sind.

Die verschiedenen Kategorien von Client Hints sind unten aufgeführt.

Benutzeragent-Client Hints

Die UA-Client Hints sind Anforderungs-Header, die Informationen über den Benutzeragenten, die Plattform/Architektur, auf der er ausgeführt wird, und Benutzereinstellungen, die auf dem Benutzeragenten oder der Plattform eingestellt sind, bereitstellen:

Sec-CH-UA Experimentell: Benutzeragenten-Marken und Version.
Sec-CH-UA-Arch Experimentell: Architektonische Plattform, auf der der Benutzeragent basiert.
Sec-CH-UA-Bitness Experimentell: Architektonische Bitigkeit (zum Beispiel "64" Bit) der CPU, auf der der Benutzeragent basiert.
Sec-CH-UA-Form-Factors Experimentell: Formfaktoren des Benutzeragenten, die beschreiben, wie der Benutzer mit dem Benutzeragenten interagiert.
Sec-CH-UA-Full-Version Veraltet: Vollständige Versionszeichenkette 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, auf der der Benutzeragent basiert.
Sec-CH-UA-Platform-Version Experimentell: Betriebssystemversion, auf der der Benutzeragent basiert.
Sec-CH-UA-WoW64 Experimentell: Ob der Benutzeragent in 32-Bit-Modus auf 64-Bit-Windows läuft.
Sec-CH-Prefers-Color-Scheme Experimentell: Benutzerpräferenz für helles oder dunkles Farbschema.
Sec-CH-Prefers-Reduced-Motion Experimentell: Benutzerpräferenz, weniger Animationen und Layoutverschiebungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anforderungs-Header gibt die Präferenz des Benutzeragenten für reduzierte Transparenz an.

Hinweis: Benutzeragent-Client Hints sind innerhalb von fenced frames nicht verfügbar, da sie auf der Permissions Policy Delegation basieren, die zum Datenleckage verwendet werden könnte.

Geräte-Client Hints

Content-DPR Veraltet Nicht standardisiert: Antwort-Header, der das Bild Device-to-Pixel-Verhältnis (DPR) in Anfragen bestätigt, in denen der Bildschirm-DPR-Client-Hint verwendet wurde, um eine Bildressource auszuwählen.
Device-Memory: Ungefähre Menge verfügbaren RAM-Speichers des Clients. Dies ist Teil der Device Memory API.
DPR Veraltet Nicht standardisiert: Anforderungs-Header, der das Clientgeräte-Pixel-Verhältnis bereitstellt (die Anzahl der physischen Geräte-Pixel pro CSS-Pixel).
Viewport-Width Veraltet Nicht standardisiert: Anforderungs-Header stellt die Layout-Viewport-Breite des Clients in CSS-Pixel bereit.
Width Veraltet Nicht standardisiert: Anforderungs-Header gibt die gewünschte Ressourcenbreite in physischen Pixeln an (die intrinsische Größe eines Bildes).

Netzwerk-Client Hints

Netzwerk-Client Hints ermöglichen es einem Server, zu entscheiden, welche Informationen basierend auf der Benutzerwahl sowie der Netzwerkbandbreite und -latenz gesendet werden sollen.

Downlink Experimentell: Ungefähre Bandbreite der Verbindung des Clients zum Server, in Mbit/s. Dies ist Teil der Network Information API.
ECT Experimentell: Der wirksame Verbindungstyp ("Netzwerkprofil"), der am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.
RTT Experimentell: Roundtrip-Zeit auf Anwendungsebene (RTT) in Millisekunden, die die Serververarbeitungszeit umfasst. Dies ist Teil der Network Information API.
Save-Data Experimentell: Ein String on, der die Präferenz des Benutzeragenten für die reduzierte Datennutzung angibt.

Transport der Kompressionswörterbuch

Transport der Kompressionswörterbuch ist eine Methode zur Verwendung eines gemeinsamen Kompressionswörterbuchs, um die Transportgröße von HTTP-Antworten zu reduzieren, anstatt das standardmäßige statische Wörterbuch in Brotli-Kompression oder Zstandard-Kompression zu nutzen.

Available-Dictionary Experimentell: Ein Browser kann diesen Anforderungs-Header verwenden, um das beste Wörterbuch, das er für die Kompression zur Verfügung hat, an den Server zu senden.
Dictionary-ID Experimentell: Wird verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource hat und der Server eine id für das Wörterbuch im Use-As-Dictionary-Header bereitgestellt hat. Anfragen nach Ressourcen, die das Wörterbuch verwenden können, haben einen Available-Dictionary-Header und die Server bereitgestellte Wörterbuch-id im Dictionary-ID-Header.
Use-As-Dictionary Experimentell: Listet die Übereinstimmungskriterien auf, für die das Wörterbuch in zukünftigen Anfragen verwendet werden kann.

Datenschutz

DNT Veraltet Nicht standardisiert: Anforderungs-Header, der die Tracking-Präferenz des Nutzers (Do Not Track) anzeigt. Veraltet zugunsten der Global Privacy Control (GPC), die Servern unter Verwendung des Sec-GPC Headers mitgeteilt wird und für Clients über navigator.globalPrivacyControl zugänglich ist.
Tk Veraltet Nicht standardisiert: Antwort-Header, der den Tracking-Status angibt, der auf die entsprechende Anfrage angewendet wurde. Wird in Verbindung mit DNT verwendet.
Sec-GPC Nicht standardisiert Experimentell: Gibt an, ob der Nutzer einem Verkauf oder Teilen ihrer persönlichen Informationen mit Dritten zustimmt.

Sicherheit

Origin-Agent-Cluster Experimentell: Antwort-Header, der verwendet wird, um anzugeben, dass das zugehörige Document in einem ursprungs-geschlüsselten Agenten-Cluster platziert werden soll. Diese Isolation ermöglicht es Benutzeragenten, implementationsspezifische Ressourcen für Agenten-Cluster, wie Prozesse oder Threads, effizienter zuzuordnen.

Vom Server gesendete Ereignisse

NEL Experimentell: Definiert einen Mechanismus, der Entwicklern ermöglicht, eine Richtlinie zur Netzwerkfehlerberichterstattung zu deklarieren.

Themen-API

Die Themen-API bietet einen Mechanismus zur Implementierung von Anwendungsfällen wie interessenbasierte Werbung (IBA). Weitere Informationen finden Sie in der Themen-API Dokumentation.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwort-Header, der verwendet wird, um beobachtete Interessenthemen anzugeben, die aus der URL der aufrufenden Seite abgeleitet wurden, wie sie in der Antwort auf eine Anfrage markiert sind, die von einer Funktion, die die Themen-API aktiviert generiert wurde.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Anforderungs-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Werbetechnologieplattform verwendet werden, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.

Sonstiges

Accept-Signature Experimentell: Ein Client kann den Accept-Signature Header senden, um auszudrücken, dass er beabsichtigt, von erhaltenen Signaturen Gebrauch zu machen, und um anzugeben, welche Arten von Signaturen er unterstützt.
Early-Data Experimentell: Gibt an, dass die Anfrage in TLS-Frühdaten übermittelt wurde.
Idempotency-Key Experimentell: Bietet einen eindeutigen Schlüssel für POST und PATCH-Anfragen, wodurch diese idempotent gemacht werden können.
Set-Login Experimentell: Antwort-Header, der von einem föderierten Identitätsanbieter (IdP) gesendet wird, um seinen Anmeldestatus festzulegen, was bedeutet, ob Benutzer auf dem aktuellen Browser bei dem IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und von der FedCM API verwendet.
Signature Experimentell: Der Signature Header-Feld überträgt eine Liste von Signaturen für ein Austausch, jede begleitet von Informationen darüber, wie die Autorisierung dieser Signaturen zu bestimmen und diese Signatur zu erneuern ist.
Signed-Headers Experimentell: Der Signed-Headers Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in einer Signatur enthalten sein sollen.
Speculation-Rules Experimentell: 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 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, so dass ein Server identifizieren kann, welche Regel(n) sie verursacht hat und möglicherweise blockieren.
Supports-Loading-Mode Experimentell: Wird von einem Navigationstarget gesetzt, um die Verwendung verschiedener risikoreicher Lademodi zu aktivieren. Zum Beispiel erfordert dasselbe Ursprungs-, gleichtätige 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 sich über einen HTTP-Proxy oder einen Lastverteiler mit einem Webserver verbindet.
X-Forwarded-Host Nicht standardisiert: Identifiziert den ursprünglichen Host, den ein Client verwendet hat, um sich mit Ihrem Proxy oder Lastenverteiler zu verbinden.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um sich mit Ihrem Proxy oder Lastenverteiler zu verbinden.
X-DNS-Prefetch-Control Nicht standardisiert: Steuert das DNS-Prefetching, eine Funktion, bei der Browser proaktiv die Domänennamenauflösung sowohl für Links durchführen, denen der Benutzer möglicherweise folgt, als auch für URLs für Elemente, die das Dokument referenziert, einschließlich Bildern, CSS, JavaScript und so weiter.
X-Robots-Tag Nicht standardisiert: Der X-Robots-Tag HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb öffentlicher Suchmaschinenergebnisse indexiert werden soll. Der Header entspricht in etwa den <meta name="robots"> Elementen.

Veraltete Header

Pragma Veraltet: Implementierungsspezifischer Header, der in der gesamten Anforderung-Antwort-Kette verschiedene Effekte haben kann. Wird zur Rückwärtskompatibilität mit HTTP/1.0-Caches verwendet, bei denen der Cache-Control-Header noch nicht vorhanden ist.
Warning Veraltet: Allgemeine Warninformationen über mögliche Probleme.

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