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-automatenensitiver Name gefolgt von einem Doppelpunkt, dann optionaler Leerzeichen, die ignoriert werden, und schließlich seinem Wert (zum Beispiel: Allow: POST). In HTTP/2 und höher werden Header in Kleinbuchstaben angezeigt, wenn sie in Entwicklerwerkzeugen betrachtet werden (accept: */*), und für eine spezielle Gruppe von Pseudo-Headern mit einem Doppelpunkt versehen (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der Seite HTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden historisch mit einem X- Präfix verwendet, aber diese Konvention wurde 2012 wegen der Unannehmlichkeiten, die es verursachte, als nichtstandardisierte Felder in RFC 6648 als Standard übernommen wurden, aufgegeben; andere sind im IANA HTTP-Feldnamen-Register aufgeführt, dessen Originalinhalt in RFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlich Informationen über ihren Status.

Header können je nach Kontext gruppiert werden:

Anfrage-Header: Enthalten mehr Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.
Antwort-Header: Enthalten zusätzliche Informationen über die Antwort, wie etwa ihren Standort oder über den Server, der sie bereitstellt.
Repräsentations-Header: Enthalten Informationen über den Body der Ressource, wie ihren MIME-Typ oder die angewendete Kodierung/Kompression.
Payload-Header: Enthalten darstellungsunabhängige Informationen über die Nutzdaten, einschließlich der Inhaltslänge und der für den Transport verwendeten Kodierung.

Header können auch je nach der Handhabung durch Proxies gruppiert werden:

End-to-End-Header: Diese Header müssen an den endgültigen Empfänger der Nachricht übertragen werden: der Server für eine Anfrage oder der Client für eine Antwort. Zwischengeschaltete Proxies müssen diese Header unverändert weiterleiten und Caches müssen sie speichern.
Hop-by-Hop-Header: Diese Header sind nur für eine einzelne transportebene Verbindung sinnvoll und dürfen nicht von Proxies weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mit dem Connection-Header eingestellt werden können.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource verwendet werden soll.
Authorization: Enthält die Anmeldeinformationen zur Authentifizierung eines Benutzeragenten bei einem Server.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die zum Zugriff auf eine Ressource hinter einem Proxy-Server verwendet werden soll.
Proxy-Authorization: Enthält die Anmeldeinformationen zur Authentifizierung eines Benutzeragenten bei einem Proxy-Server.

Caching

Age: Die Zeit, in Sekunden, die das Objekt in einem Proxy-Cache ist.
Cache-Control: Direktiven für Caching-Mechanismen in sowohl Anfragen als auch Antworten.
Clear-Site-Data: Löscht Browsing-Daten (z.B. Cookies, Speicher, Cache), die mit der anfragenden Website verbunden sind.
Expires: Das Datum/die Uhrzeit, nach der die Antwort als veraltet angesehen wird.
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 soll.

Konditionale

Last-Modified: Das letzte Änderungsdatum 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. Konditionale 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. Konditionale Anfragen, die If-Match und If-None-Match verwenden, nutzen diesen Wert, um das Verhalten der Anfrage zu ändern.
If-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.
If-None-Match: Macht die Anfrage bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit keinem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anfragen), oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine existiert.
If-Modified-Since: Macht die Anfrage bedingt und erwartet, dass die Ressource nur gesendet 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 gesendet wird, wenn sie nach dem angegebenen Datum nicht geändert wurde. Dies gewährleistet die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit vorherigen, oder um ein optimistisches Sperrsteuerungssystem beim Ändern vorhandener Dokumente umzusetzen.
Vary: Bestimmt, wie die Anfrage-Header abgestimmt 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 offen bleibt.
Keep-Alive: Steuert, wie lange eine beständige Verbindung offen bleiben soll.

Inhaltsverhandlung

Weitere Informationen finden Sie im Artikel zur Inhaltsverhandlung.

Accept: Informiert den Server über die Typen von Daten, die zurückgesendet werden können.
Accept-Encoding: Der Kodierungsalgorithmus, normalerweise ein Komprimierungsalgorithmus, der auf die zurückgesandte Ressource angewendet werden kann.
Accept-Language: Informiert den Server über die menschliche Sprache, die der Server zurückgeben soll. Dies ist ein Hinweis und steht nicht unbedingt unter der vollständigen Kontrolle des Benutzers: Der Server sollte immer darauf achten, eine explizite Benutzerwahl (wie die Auswahl einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.
Accept-Patch: Ein request content negotiation-Antwortheader, der angibt, welchen Medientyp der Server in einer PATCH-Anfrage versteht.
Accept-Post: Ein request content negotiation-Antwortheader, der angibt, welchen Medientyp der Server in einer POST-Anfrage versteht.

Steuerungen

Expect: Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anfrage korrekt zu bearbeiten.
Max-Forwards: Bei Verwendung von TRACE gibt er die maximale Anzahl von Hops 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 Benutzeragenten.

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 Berechtigungsflag auf true gesetzt 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 bei der Antwort auf eine Preflight-Anfrage beim Zugriff auf die Ressource 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 im Cache gespeichert werden können.
Access-Control-Request-Headers: Wird bei der Ausgabe einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird bei der Ausgabe 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, die es sehen dürfen, welche Werte von Attributen über die Funktionen der Resource Timing API abgerufen wurden, die ansonsten aufgrund von Cross-Origin-Beschränkungen als Null gemeldet würden.

Downloads

Content-Disposition: Gibt an, ob die übertragene Ressource inline angezeigt werden soll (Standardverhalten ohne den Header) oder ob sie wie ein Download behandelt werden soll und der Browser einen "Speichern unter"-Dialog präsentieren soll.

Integritätsdigests

Content-Digest Experimentell: Bietet einen Digest des Datenstreams, der in einer HTTP-Nachricht umrahmt ist (der Nachrichteninhalt), abhängig von Content-Encoding und Content-Range.
Repr-Digest Experimentell: Bietet einen Digest der ausgewählten Repräsentation der Zielressource vor der Übertragung. Im Gegensatz zu Content-Digest wird hierbei Content-Encoding oder Content-Range nicht berücksichtigt.
Want-Content-Digest Experimentell: Gibt den Wunsch nach einem Content-Digest-Header an. Es ist das Content- Gegenstück zu Want-Repr-Digest.
Want-Repr-Digest Experimentell: Gibt den Wunsch nach einem Repr-Digest-Header an. Es ist das Repr- Gegenstück zu Want-Content-Digest.

Integritätsrichtlinie

Integrity-Policy: Stellt sicher, dass alle vom Benutzeragenten geladenen Ressourcen (einer bestimmten Art) Subressourcen-Integrität garantieren.
Integrity-Policy-Report-Only: Meldet, welche Ressourcen der Benutzeragent lädt, die gegen die Subresource Integrity-Garantien verstoßen würden, wenn die Integritätsrichtlinie durchgesetzt würde (unter Verwendung des Integrity-Policy-Headers).

Informationsaustausch der Nachrichtenkörper

Content-Length: Die Größe der Ressource in Dezimalbytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Wird verwendet, um den Komprimierungsalgorithmus anzugeben.
Content-Language: Beschreibt die menschliche Sprache(n) für das Publikum, um eine Differenzierung entsprechend der bevorzugten Sprache der Nutzer zu ermöglichen.
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 angewendet wird, in Fällen, in denen sie sonst für den Client unklar wäre. Browser haben keine native Handhabung zum Senden von Präferenzen über diese Header; sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.

Prefer: Gibt Präferenzen für bestimmte Serververhalten 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 Präferenzen im Prefer-Header vom Server angewendet wurden. Es ist ein Antwort-Header, der Transparenz über die Präferenzbehandlung bietet.

Proxies

Forwarded: Enthält Informationen von der clientseitigen Seite von Proxy-Servern, die geändert oder verloren gehen, wenn ein Proxy am Pfad der Anfrage beteiligt ist.
Via: Wird von Proxies hinzugefügt, sowohl von Weiterleitungs- als auch von Reverse-Proxies, und kann sowohl in Anfragen-Headern als auch in Antwort-Headern 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 möchten, einen Download zu unterbrechen und fortzusetzen.

Accept-Ranges: Gibt an, ob der Server Bereichsanfragen 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 Bereichsanfrage, die nur erfüllt wird, wenn der angegebene ETag oder das Datum mit der Remote-Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen von inkompatiblen Versionen der Ressource zu verhindern.
Content-Range: Gibt an, wo in einer vollständigen Nachrichtenblöcke eine partielle Nachricht gehört.

Weiterleitungen

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

Anforderungskontext

From: Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden Benutzeragenten steuert.
Host: Gibt den Domainnamen des Servers an (für virtuelles Hosting) sowie (optional) die TCP-Portnummer, auf der der Server zuhört.
Referer: Die Adresse der vorherigen Webseite, von der aus ein Link zur derzeit angeforderten Seite gefolgt wurde.
Referrer-Policy: Bestimmt, welche Referrer-Informationen, die im Referer-Header gesendet werden, mit Anfragen eingeschlossen werden sollen.
User-Agent: Enthält einen charakteristischen String, der es Netzwerkprotokollpartnern ermöglicht, die Anwendungstyp, Betriebssystem, Softwareanbieter oder Softwareversion des anfordernden Software-Benutzeragenten zu identifizieren.

Antwortkontext

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

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Ermöglicht es einem Server, eine Einbettungsrichtlinie 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): Steuert Ressourcen, die der Benutzeragent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Ermöglicht es Webentwicklern, mit Richtlinien zu experimentieren, indem sie deren Effekte überwachen, aber nicht durchsetzen. Diese Verstöße Berichte bestehen aus JSON Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.
Expect-CT Veraltet: Ermöglicht es Websites, die Meldung und Durchsetzung der Zertifikatstransparenz zu melden, um die Verwendung von fehlerhaft ausgestellten Zertifikaten für diese Seite zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Verwendung von Browserfunktionen in einer Websiteeigener Frame sowie in <iframe>s, die sie einbettet, zu erlauben und zu verweigern.
Reporting-Endpoints Experimentell: Antwort-Header, der Websitebesitzern ermöglicht, einen oder mehrere Endpunkte anzugeben, die verwendet werden, um Fehler wie CSP-Verstöße, Cross-Origin-Opener-Policy-Berichte oder andere generische Verstöße zu erhalten.
Strict-Transport-Security (HSTS): Erzwingt die Kommunikation über HTTPS anstelle von HTTP.
Upgrade-Insecure-Requests: Sendet ein Signal an den Server, das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt, und dass er die upgrade-insecure-requests-Direktive erfolgreich handhaben kann.
X-Content-Type-Options: Deaktiviert MIME-Sniffing und erzwingt, dass der Browser den im Content-Type angegebenen Typ verwendet.
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 Ccross-Domain-Policy-Datei kann Clients wie Adobe Acrobat oder Apache Flex (unter anderen) die Berechtigung erteilen, Daten domainsübergreifend zu behandeln, die ansonsten aufgrund der Same-Origin-Policy beschränkt wären. Der X-Permitted-Cross-Domain-Policies-Header überschreibt solche Policy-Dateien, sodass Clients unerwünschte Anfragen dennoch blockieren.
X-Powered-By: Kann von Hosting-Umgebungen oder anderen Frameworks festgelegt werden und enthält Informationen über diese, ohne dass sie für die Anwendung oder ihre Besucher von Nutzen sind. Entfernen Sie diesen Header, um potenzielle Schwachstellen zu verbergen.
X-XSS-Protection: Aktiviert die Filterung von Cross-Site-Scripting.

Fetch-Metadaten-Anforderungs-Header

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

Sec-Fetch-Site: Gibt die Beziehung zwischen dem Ursprung eines Anforderungsinitiators und dessen Zielursprung an. Es ist ein strukturierter Header, dessen Wert ein Token ist, mit möglichen Werten cross-site, same-origin, same-site und none.
Sec-Fetch-Mode: Gibt den Modus der Anfrage an einen Server an. Es ist ein strukturierter Header, dessen Wert ein Token ist, mit möglichen Werten cors, navigate, no-cors, same-origin und websocket.
Sec-Fetch-User: Gibt an, ob eine Navigationsanforderung durch Benutzeraktivierung ausgelöst wurde oder nicht. Es ist ein strukturierter Header, dessen Wert ein Boolean ist, daher sind mögliche Werte ?0 für falsch und ?1 für wahr.
Sec-Fetch-Dest: Gibt das Ziel der Anfrage an. Es ist ein strukturierter Header, dessen Wert ein Token ist, mit möglichen Werten audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker und xslt.

Die folgenden Anforderungs-Header sind nicht streng "Fetch-Metadaten-Anforderungs-Header", liefern aber ähnlich Informationen darüber, wie eine Ressource verwendet wird. Ein Server könnte sie verwenden, um sein Cache-Verhalten zu modifizieren oder die Informationen, die zurückgegeben werden:

Sec-Purpose: Gibt den Zweck der Anfrage an, wenn der Zweck etwas anderes als die sofortige Nutzung durch den Benutzeragenten ist. Der Header hat derzeit einen möglichen Wert, prefetch, der anzeigt, dass die Ressource vorsorglich für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungs-Header, der in einer vorab ausgeführten Anfrage genutzt wird, um eine Ressource während des Service-Worker-Starts mit fetch() abzurufen. Der Wert, der mit NavigationPreloadManager.setHeaderValue() festgelegt wird, kann verwendet werden, um einem Server mitzuteilen, dass eine andere Ressource zurückgegeben werden sollte als bei einem normalen fetch()-Vorgang.

Fetch-Speicherzugriffs-Header

Diese Header ermöglichen einen erweiterten 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 ist. Der Server kann mit Activate-Storage-Access antworten, um den Browser zu bitten, eine inactive Berechtigung zu aktivieren und die Anfrage mit Zugriff auf seine Drittanbieter-Cookies zu wiederholen, oder um eine Ressource zu laden, wenn bereits eine aktivierte Berechtigung vorhanden ist.
Activate-Storage-Access: Wird als Antwort auf Sec-Fetch-Storage-Access verwendet, um anzuzeigen, dass der Browser eine vorhandene Berechtigung für sicheren Zugriff aktivieren und die Anfrage mit Cookies wiederholen kann oder eine Ressource mit Cookie-Zugriff laden kann, wenn er bereits über eine aktivierte Berechtigung verfügt.

Vom Server gesendete Ereignisse

Reporting-Endpoints: Antwort-Header, der verwendet wird, um Server-Endpunkte anzugeben, wohin der Browser Warnungen und Fehlermeldungen senden soll, wenn er die Reporting API verwendet.
Report-To Veraltet Nicht standardisiert: Antwort-Header, der verwendet wird, um Server-Endpunkte anzugeben, wohin der Browser Warnungen und Fehlermeldungen senden soll, wenn er die Reporting API verwendet.

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 Transfer-Codierungen an, die der Benutzeragent zu akzeptieren bereit ist.
Trailer: Ermöglicht dem Absender, zusätzliche Felder am Ende eines chunked-Nachrichten zu inkludieren.

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 aufzurüsten.
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-Präferenzen ausgewählte Erweiterung an.
Sec-WebSocket-Key: Anforderungs-Header, der einen Schlüssel enthält, der überprüft, dass der Client explizit beabsichtigt, einen WebSocket zu öffnen.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die vom Client in bevorzugter Reihenfolge unterstützten Subprotokolle an. In Antworten gibt er das vom Server aus den Client-Präferenzen ausgewählte Subprotokoll an.
Sec-WebSocket-Version: In Anfragen gibt dieser Header die vom Client verwendete Version des WebSocket-Protokolls an. In Antworten wird er nur gesendet, wenn die angeforderte Protokollversion vom Server nicht unterstützt wird und listet die vom Server unterstützten Versionen auf.

Sonstiges

Alt-Svc: Wird verwendet, um alternative Möglichkeiten zur Erreichung dieses Dienstes aufzulisten.
Alt-Used: Wird verwendet, um den verwendeten alternativen Dienst zu identifizieren.
Date: Enthält das Datum und die Uhrzeit, zu der die Nachricht erstellt wurde.
Link: Dieses Entität-Header-Feld bietet ein Mittel, um einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zu dem HTML <link>-Element.
Retry-After: Gibt an, wie lange der Benutzeragent warten soll, bevor eine Folgeanfrage gestellt wird.
Server-Timing: Übermittelt eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.
Service-Worker: Wird in Fetches für ein Skript-Ressource eines Service Workers aufgenommen. Dieser Header hilft Administratoren, Service Worker-Skriptanforderungen zur Überwachung zu protokollieren.
Service-Worker-Allowed: Wird verwendet, um die Pfadbeschränkung zu entfernen, indem dieser Header in der Antwort des Service Worker-Skripts aufgenommen wird.
SourceMap: Verknüpft mit einer Source Map, damit Debugger im Originalquellcode anstelle des generierten oder transformierten Codes durchgehen können.
Upgrade: Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung zu einem anderen Protokoll (über dasselbe Transportprotokoll) aufzurüsten. Zum Beispiel kann er von einem Client verwendet werden, um eine Verbindung von HTTP 1.1 zu HTTP 2.0 aufzurüsten oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket umzuwandeln.
Priority: Bereitstellt einen Hinweis über die Priorität einer bestimmten Ressourcenanforderung 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 die Anfrage neubewertet.

Experimentelle Header

Attributionsberichte-Header

Die Attribution Reporting API ermöglicht Entwicklern das Messen von Konversionen - beispielsweise, wenn ein Benutzer auf eine auf einer Seite eingebettete Anzeige klickt und dann auf der Website des Anbieters das Produkt kauft - und anschließend Berichte zu diesen Konversionen zuzugreifen. Sie tut dies, ohne auf Drittanbieter-Tracking-Cookies angewiesen zu sein, und vertraut stattdessen auf verschiedene Header, um Quellen und Auslöser zu registrieren, die auf eine Konversion hinweisen.

Attribution-Reporting-Eligible: Wird verwendet, um anzuzeigen, dass die Antwort, die der aktuellen Anfrage entspricht, zur Teilnahme an Attributionsberichten berechtigt ist, indem entweder eine Attributionsquelle oder ein Auslöser registriert wird.
Attribution-Reporting-Register-Source: Ist als Teil einer Antwort auf eine Anfrage enthalten, die einen Attribution-Reporting-Eligible-Header enthielt, und wird verwendet, um eine Attributionsquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Ist als Teil einer Antwort auf eine Anfrage enthalten, die einen Attribution-Reporting-Eligible-Header enthielt, und wird verwendet, um einen Attributionsauslöser zu registrieren.

Client-Hinweise

HTTP-Client-Hinweise sind eine Gruppe von Anforderungs-Headern, die nützliche Informationen über den Client bereitstellen, wie Gerätetyp und Netzwerkbedingungen, und Servern erlauben, das, was geliefert wird, für diese Bedingungen zu optimieren.

Server fordern proaktiv die Client-Hinweis-Header, an denen sie vom Client interessiert sind, mithilfe von Accept-CH an. Der Client kann dann wählen, ob er die angeforderten Header in nachfolgenden Anfragen einschließt.

Accept-CH: Server können Unterstützung für Client-Hinweise durch das Accept-CH-Header-Feld oder ein gleichwertiges HTML <meta>-Element mit dem http-equiv Attribut angeben.
Critical-CH Experimentell: 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 aufgeführt.

User Agent Client-Hinweise

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

Sec-CH-UA Experimentell: Marke und Version des Benutzeragenten.
Sec-CH-UA-Arch Experimentell: Die zugrunde liegende Plattformarchitektur des Benutzeragenten.
Sec-CH-UA-Bitness Experimentell: Bitbreite der zugrunde liegenden CPU-Architektur des Benutzeragenten (zum Beispiel "64" bit).
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 Versionszeichenfolge des Benutzeragenten.
Sec-CH-UA-Full-Version-List Experimentell: Vollversion 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 allgemeiner gesagt eine "mobile" Benutzererfahrung.
Sec-CH-UA-Model Experimentell: Modell des Benutzergeräts.
Sec-CH-UA-Platform Experimentell: Das zugrunde liegende Betriebssystem/Plattform des Benutzeragenten.
Sec-CH-UA-Platform-Version Experimentell: Versionsnummer des zugrunde liegenden Betriebssystems des Benutzeragenten.
Sec-CH-UA-WoW64 Experimentell: Ob der Benutzeragenten-Binary im 32-Bit-Modus auf 64-Bit-Windows ausgeführt wird oder nicht.
Sec-CH-Prefers-Color-Scheme Experimentell: Bevorzugung des Nutzers für ein dunkles oder helles Farbschema.
Sec-CH-Prefers-Reduced-Motion Experimentell: Bevorzugung des Nutzers, weniger Animationen und Inhaltslayout-Änderungen zu sehen.
Sec-CH-Prefers-Reduced-Transparency Experimentell: Anforderungs-Header, der die Vorliebe des Benutzeragenten für reduzierte Transparenz angibt.

Hinweis: Benutzeragent-Client-Hinweise sind nicht innerhalb von eingezäunten Frames verfügbar, da sie auf Berechtigungsrichtlinien-Delegation beruhen, die verwendet werden könnte, um Daten zu leaken.

Geräte-Client-Hinweise

Content-DPR Veraltet Nicht standardisiert: Antwort-Header, der das Bildgerät zum Pixelverhältnis (DPR) in Anfragen bestätigt, bei denen der Bildschirm-DPR-Client-Hinweis verwendet wurde, um eine Bildressource auszuwählen.
Device-Memory: Ungefähre Menge des verfügbarem RAM-Speichers des Clients. Dies ist Teil der Device Memory API.
DPR Veraltet Nicht standardisiert: Anforderungs-Header, der das Pixelverhältnis des Clientgeräts angibt (die Anzahl der physischen Gerätepixel für jedes CSS-Pixel).
Viewport-Width Veraltet Nicht standardisiert: Anforderungs-Header, der die Breite des Layout-Viewports des Clients in CSS-Pixeln angibt.
Width Veraltet Nicht standardisiert: Anforderungs-Header, der die gewünschte Ressourcenbreite in physischen Pixeln angibt (die inhärente Größe einer Bildressource).

Netzwerk-Client-Hinweise

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

Downlink Experimentell: Ungefähre Bandbreite der Verbindung des Clients zum Server in Mbps. Dies ist Teil der Network Information API.
ECT Experimentell: Der effektiver Verbindungstyp ("Netzwerkprofil"), das am besten zur Latenz und Bandbreite der Verbindung passt. Dies ist Teil der Network Information API.
RTT Experimentell: Anwendungsrundfahrtzeit (RTT) in Millisekunden, die die Serververarbeitungszeit einschließt. Dies ist Teil der Network Information API.
Save-Data Experimentell: Eine Zeichenfolge on, die die Vorliebe des Benutzeragenten für reduzierte Datennutzung angibt.

Kompressionswörterbuchtransport

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

Available-Dictionary Experimentell: Ein Browser kann diesen Anforderungs-Header verwenden, um das beste Wörterbuch anzugeben, das er für den Server verfügbar hat, um Kompression zu verwenden.
Dictionary-ID Experimentell: 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 Experimentell: Listet die passenden Kriterien auf, die das Wörterbuch für zukünftige Anfragen verwenden kann.

Datenschutz

DNT Veraltet Nicht standardisiert: Anforderungs-Header, der die Benutzerpräferenz zum Tracking (Do Not Track) angibt. Veraltet zugunsten der Global Privacy Control (GPC), die mittels Sec-GPC-Header an Server kommuniziert und über navigator.globalPrivacyControl für Clients zugänglich ist.
Tk Veraltet Nicht standardisiert: Antwort-Header, der den Tortus-Status angibt, der für die entsprechende Anfrage galt. Wird in Verbindung mit DNT verwendet.
Sec-GPC Nicht standardisiert Experimentell: Gibt an, ob der Benutzer einwilligt, dass eine Website oder ein Dienst seine persönlichen Informationen an Dritte verkauft oder teilt.

Sicherheit

Origin-Agent-Cluster Experimentell: Antwort-Header verwendet, um anzuzeigen, dass das zugehörige Document in einen ursprungs-gelagerten Agent Cluster platziert werden soll. Diese Isolation ermöglicht es Benutzeragenten, ressourcenspezifische Ressourcen für Agent Cluster wie Prozesse oder Threads effizienter zuzuweisen.

Vom Server gesendete Ereignisse

NEL Experimentell: Definiert einen Mechanismus, der Entwicklern ermöglicht, eine Netzwerkfehler-Meldungspolitik festzulegen.

Themen-API

Die Themen-API bietet Entwicklern einen Mechanismus, um Anwendungsfälle wie interessenbasierte Werbung (IBA) zu implementieren. Weitere Informationen finden Sie in der Themen-API Dokumentation.

Observe-Browsing-Topics Experimentell Nicht standardisiert: Antwort-Header, der verwendet wird, um Themen von Interesse zu markieren, die aus der URL der anrufenden Webseite abgeleitet werden, wie sie als Antwort auf eine Anfrage erkannt wurden, die durch eine Funktion, die die Themen-API ermöglicht, generiert wurde.
Sec-Browsing-Topics Experimentell Nicht standardisiert: Anforderungs-Header, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Werbetechnologie-Plattform verwendet werden, um eine personalisierte Anzeige auszuwählen, die angezeigt werden soll.

Sonstiges

Accept-Signature Experimentell: Ein Client kann das Accept-Signature Header-Feld senden, um die Absicht anzuzeigen, alle verfügbaren Signaturen zu nutzen und um anzugeben, welche Arten von Signaturen es unterstützt.
Early-Data Experimentell: Weist darauf hin, dass die Anfrage in TLS-Frühdaten übermittelt wurde.
Idempotency-Key Experimentell: Bietet einen eindeutigen Schlüssel für POST- und PATCH-Anfragen, damit sie idempotent gemacht werden können.
Set-Login Experimentell: Antwort-Header, gesendet von einem föderierten Identitätsanbieter (IdP), um seinen Anmeldestatus festzulegen, was bedeutet, ob Benutzer auf dem aktuellen Browser beim IdP angemeldet sind oder nicht. Dies wird vom Browser gespeichert und wird von der FedCM API verwendet.
Signature Experimentell: Das Signature Header-Feld überträgt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie die Autorität dieser Signatur bestimmt und erneuert wird.
Signed-Headers Experimentell: Das Signed-Headers Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur einbezogen werden sollen.
Speculation-Rules Experimentell: Bietet eine Liste von URLs, die auf Textressourcen verweisen, die Spekulationsregeln JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zum Spekulationsregel-Set des Dokuments hinzugefügt.
Sec-Speculation-Tags Experimentell: 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 hat und sie möglicherweise blockiert.
Supports-Loading-Mode Experimentell: Wird von einem Navigationsziel festgelegt, um die Verwendung verschiedener risikoreicherer Lademodi zu ermöglichen. Zum Beispiel erfordert das Cross-Origin/Same-Site-Prerendering einen Supports-Loading-Mode-Wert von credentialed-prerender.

Nicht-standardmäßige Header

X-Forwarded-For Nicht standardisiert: Identifiziert die ursprünglichen IP-Adressen eines Clients, der über einen HTTP-Proxy oder einen Load Balancer eine Verbindung zu einem Webserver herstellt.
X-Forwarded-Host Nicht standardisiert: Identifiziert den ursprünglichen Host, den ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Load Balancer herzustellen.
X-Forwarded-Proto Nicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Load Balancer herzustellen.
X-DNS-Prefetch-Control Nicht standardisiert: Steuert das DNS-Prefetching, eine Funktion, bei der Browser proaktiv die Domainnamenauflösung für sowohl Links, denen der Benutzer möglicherweise folgen möchte, als auch URLs von Elementen, die im Dokument referenziert werden, einschließlich Bilder, CSS, JavaScript usw., ausführen.
X-Robots-Tag Nicht standardisiert: Der X-Robots-Tag HTTP-Header wird verwendet, um anzugeben, wie eine Webseite innerhalb der öffentlichen Suchmaschinen-Ergebnisse indexiert werden soll. Der Header ist äquivalent zu <meta name="robots">-Elementen.

Veraltete Header

Pragma Veraltet: Implementierungsspezifischer Header, der überall in der Anfrage-Antwort-Kette verschiedene Effekte haben kann. Wird für die Abwärtskompatibilität mit HTTP/1.0-Caches verwendet, wenn der Cache-Control-Header noch nicht vorhanden ist.
Warning Veraltet: Allgemeine Warninformation ü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