Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten.Erfahre mehr über dieses Experiment.

View in EnglishAlways switch to English

HTTP-Header

HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Nachricht in einer Anforderung oder Antwort zu übermitteln. In HTTP/1.X ist ein Header ein nicht groß-/kleinschreibungssensitiver Name, gefolgt von einem Doppelpunkt, optionalen Leerzeichen, die ignoriert werden, und schließlich dem Wert (zum Beispiel:Allow: POST). In HTTP/2 und höher werden Header in Kleinbuchstaben angezeigt, wenn sie in Entwicklertools betrachtet werden (accept: */*), und für eine spezielle Gruppe vonPseudo-Headern mit einem Doppelpunkt versehen (:status: 200). Weitere Informationen zur Syntax in jeder Protokollversion finden Sie auf der SeiteHTTP-Nachrichten.

Benutzerdefinierte proprietäre Header wurden historisch mit einemX- Präfix verwendet, aber diese Konvention wurde 2012 aufgrund der Unannehmlichkeiten, die sie verursachte, als nicht-standardisierte Felder standardisiert wurden, inRFC 6648 abgelehnt; andere sind imIANA HTTP Field Name Registry aufgeführt, dessen originaler Inhalt inRFC 4229 definiert wurde. Das IANA-Register listet Header auf, einschließlichInformationen über ihren Status.

Header können nach ihren Kontexten gruppiert werden:

Anforderungsheader: Enthalten weitere Informationen über die abzurufende Ressource oder über den Client, der die Ressource anfordert.
Antwortheader: Enthalten zusätzliche Informationen über die Antwort, wie ihren Standort oder über den Server, der sie bereitstellt.
Repräsentationsheader: Enthalten Informationen über den Körper der Ressource, wie ihrenMIME-Typ oder angewendete Kodierung/Kompression.
Nutzdaten-Header: Enthalten sprachunabhängige Informationen über Nutzdaten, einschließlich der Inhaltslänge und der für den Transport verwendeten Kodierung.

Header können auch danach gruppiert werden, wieProxyserver sie verarbeiten:

End-to-End-Header: Diese Headermüssen an den endgültigen Empfänger der Nachricht übertragen werden: den Server bei einer Anforderung oder den Client bei einer Antwort. Zwischengeschaltete 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 Transportebene-Verbindung sinnvoll und dürfennicht von Proxys weitergeleitet oder zwischengespeichert werden. Beachten Sie, dass nur Hop-by-Hop-Header mit demConnection Header gesetzt werden dürfen.

Authentifizierung

WWW-Authenticate: Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource zuzugreifen.
Authorization: Enthält die Anmeldeinformationen, um einen User-Agent bei einem Server zu authentifizieren.
Proxy-Authenticate: Definiert die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource hinter einem Proxyserver zuzugreifen.
Proxy-Authorization: Enthält die Anmeldeinformationen, um einen User-Agent bei einem Proxyserver zu authentifizieren.

Caching

Age: Die Zeit in Sekunden, die das Objekt in einem Proxy-Cache ist.
Cache-Control: Anweisungen für Caching-Mechanismen in sowohl Anfragen als auch Antworten.
Clear-Site-Data: Löscht Browserdaten (z. B. Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind.
Expires: Das Datum/Uhrzeit, nach dem die Antwort als veraltet angesehen wird.
No-Vary-SearchExperimentell: Gibt einen Regelsatz an, der definiert, wie Abfrageparameter einer URL das Cache-Matching beeinflussen. Diese Regeln bestimmen, ob dieselbe URL mit unterschiedlichen URL-Parametern als separate Browser-Cache-Einträge gespeichert werden sollte.

Bedingte Anfragen

Last-Modified: Das Datum der letzten Änderung der Ressource, verwendet, um mehrere Versionen derselben Ressource zu vergleichen. Es ist weniger genau alsETag, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anfragen unter Verwendung vonIf-Modified-Since undIf-Unmodified-Since verwenden diesen Wert, um das Verhalten der Anforderung zu ändern.
ETag: Ein eindeutiger String, der die Version der Ressource identifiziert. Bedingte Anfragen unter Verwendung vonIf-Match undIf-None-Match verwenden diesen Wert, um das Verhalten der Anforderung zu ändern.
If-Match: Macht die Anforderung bedingt und wendet die Methode nur an, wenn die gespeicherte Ressource mit einem der angegebenen ETags übereinstimmt.
If-None-Match: Macht die Anforderung bedingt und wendet die Methode nur an, wenn die gespeicherte Ressourcenicht mit einem der angegebenen ETags übereinstimmt. Dies wird verwendet, um Caches zu aktualisieren (für sichere Anforderungen) oder um das Hochladen einer neuen Ressource zu verhindern, wenn bereits eine vorhanden ist.
If-Modified-Since: Macht die Anforderung bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum modifiziert wurde. Dies wird verwendet, um Daten nur zu übertragen, wenn der Cache veraltet ist.
If-Unmodified-Since: Macht die Anforderung bedingt und erwartet, dass die Ressource nur übertragen wird, wenn sie nach dem angegebenen Datum nicht modifiziert wurde. Dies gewährleistet die Kohärenz eines neuen Fragments eines bestimmten Bereichs mit früheren oder um ein optimistisches Sperrkontrollsystem beim Ändern vorhandener Dokumente zu implementieren.
Vary: Bestimmt, wie Anforderungsheader verglichen werden, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anfordern zu müssen.

Verbindungsverwaltung

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

Inhaltshandelsmechanismus

Weitere Details finden Sie imArtikel zum Inhaltshandelsmechanismus.

Accept: Informiert den Server über dieTypen von Daten, die zurückgesendet werden können.
Accept-Encoding: Der Kodierungsalgorithmus, gewöhnlich einKompressionsalgorithmus, 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 nicht unbedingt vollständig unter der Kontrolle des Benutzers: Der Server sollte immer achten, um eine explizite Benutzerwahl (wie z. B. die Auswahl einer Sprache aus einem Dropdown-Menü) nicht zu überschreiben.
Accept-Patch: EinAnforderungsinhaltshandels- Antwortheader, der angibt, welchenMedientyp der Server in einerPATCH-Anforderung verstehen kann.
Accept-Post: EinAnforderungsinhaltshandels- Antwortheader, der angibt, welchenMedientyp der Server in einerPOST-Anforderung verstehen kann.

Steuerungen

Expect: Gibt Erwartungen an, die vom Server erfüllt werden müssen, um die Anforderung ordnungsgemäß zu verarbeiten.
Max-Forwards: Bei Verwendung vonTRACE, gibt an, wie viele Sprünge die Anforderung machen kann, bevor sie an den Absender zurückgespiegelt wird.

Cookies

Cookie: Enthält gespeicherteHTTP-Cookies, die zuvor vom Server mit demSet-Cookie-Header gesendet wurden.
Set-Cookie: Sendet Cookies vom Server an den User-Agent.

CORS

Für weitere Informationen siehe dieCORS-Dokumentation.

Access-Control-Allow-Credentials: Zeigt an, ob die Antwort auf die Anforderung offengelegt werden kann, wenn das Berechtigungsflag wahr ist.
Access-Control-Allow-Headers: Wird als Antwort auf eineVorab-Anfrage verwendet, um anzuzeigen, welche HTTP-Header bei der tatsächlichen Anforderung verwendet werden können.
Access-Control-Allow-Methods: Gibt die Methoden an, die beim Zugriff auf die Ressource als Antwort auf eine Vorab-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 Vorab-Anfrage zwischengespeichert werden können.
Access-Control-Request-Headers: Wird beim Ausstellen einer Vorab-Anfrage verwendet, um den Server zu informieren, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden.
Access-Control-Request-Method: Wird beim Ausstellen einer Vorab-Anfrage verwendet, um den Server zu informieren, welcheHTTP-Methode bei der tatsächlichen Anfrage verwendet wird.
Origin: Zeigt an, woher ein Abruf stammt.
Timing-Allow-Origin: Gibt Ursprünge an, die berechtigte Werte von Attributen, die über Funktionen derResource Timing API abgerufen werden, sehen dürfen, die andernfalls aufgrund von Cross-Origin-Beschränkungen als null gemeldet werden würden.

Downloads

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

Integritäts-Digests

Content-DigestExperimentell: Bietet einen Digest des Stroms von Oktetten, die in einer HTTP-Nachricht gerahmt sind (der Nachrichteninhalt), abhängig vonContent-Encoding undContent-Range.
Repr-DigestExperimentell: Bietet einen Digest der ausgewählten Darstellung der Zielressource vor der Übertragung.Im Gegensatz zumContent-Digest berücksichtigt der Digest nichtContent-Encoding oderContent-Range.
Want-Content-DigestExperimentell: Gibt den Wunsch nach einem Content-Digest-Header an.Es ist dasContent--Analogon zurWant-Repr-Digest.
Want-Repr-DigestExperimentell: Gibt den Wunsch nach einem Repr-Digest-Header an.Es ist dasRepr--Analogon zurWant-Content-Digest.

Integritätsrichtlinie

Integrity-Policy: Stellt sicher, dass alle vom User-Agent geladenen Ressourcen (eines bestimmten Typs) Garantien zurSubresource Integrity haben.
Integrity-Policy-Report-Only: Berichtet über Ressourcen, die der User-Agent lädt, die gegenSubresource Integrity verstoßen würden, wenn die Integritätsrichtlinie durchgesetzt würde (mithilfe desIntegrity-Policy-Headers).

Informationen zum Nachrichtentext

Content-Length: Die Größe der Ressource in dezimaler Anzahl von Bytes.
Content-Type: Gibt den Medientyp der Ressource an.
Content-Encoding: Verwendet, um den Kompressionsalgorithmus anzugeben.
Content-Language: Beschreibt die menschliche Sprache(n), die für das Publikum bestimmt sind, sodass ein Benutzer sie entsprechend den eigenen bevorzugten Sprachen differenzieren kann.
Content-Location: Gibt einen alternativen Speicherort 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 es für den Client sonst nicht klar wäre. Browser haben keine native Verarbeitung zum Senden von Präferenzen über diese Header; sie werden in benutzerdefinierten, Implementierungsspezifischen Clients verwendet.

Prefer: Gibt Präferenzen für spezifische Serververhalten während der Anforderungsverarbeitung an. Beispielsweise kann sie minimalen Antwortinhalt (return=minimal) oder asynchrone Verarbeitung (respond-async) anfordern. Der Server verarbeitet die Anforderung normalerweise, wenn der Header nicht unterstützt wird.
Preference-Applied: Informiert den Client, welche in demPrefer-Header angegebenen Präferenzen vom Server angewendet wurden. Es ist ein reiner Antwort-Header, der Transparenz über die Präferenzbehandlung bietet.

Proxy

Forwarded: Enthält Informationen von der dem Client zugewandten Seite von Proxyservern, die verändert oder verloren gehen, wenn ein Proxy am Pfad der Anfrage beteiligt ist.
Via: Hinzugefügt durch Proxys, sowohl vorwärts- als auch rückwärtsgewandte Proxys, und kann in den Anforderungs- und Antwort-Headern erscheinen.

Bereichsanfragen

HTTP-Bereichsanfragen ermöglichen es dem Client, einen Teil einer Ressource vom Server anzufordern. Bereichsanfragen sind nützlich für Anwendungen wie Mediaplayer, die zufälligen Zugriff unterstützen, Datentools, die 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 in welcher Einheit der Bereich ausgedrückt werden kann.
Range: Gibt an, welchen Teil eines Dokuments 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 entfernten 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 Nachricht ein Teil der Nachricht hingehört.

Umleitungen

Location: Gibt die URL an, auf die eine Seite umgeleitet werden soll.
Refresh: Fordert den Browser auf, die Seite neu zu laden oder zu einer anderen zu wechseln. Nimmt denselben Wert an wie dasmeta Element mithttp-equiv="refresh".

Anforderungskontext

From: Enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfordernden User-Agent kontrolliert.
Host: Gibt den Domainnamen des Servers an (für virtuelles Hosting) und (optional) die TCP-Portnummer, auf der der Server lauscht.
Referer: Die Adresse der vorherigen Webseite, von der aus ein Link zur aktuell angeforderten Seite gefolgt wurde.
Referrer-Policy: Bestimmt, welche Referrer-Informationen, die imReferer-Header gesendet werden, bei Anfragen einbezogen werden sollen.
User-Agent: Enthält einen charakteristischen String, der es Netzwerkprotokoll-Partnern ermöglicht, den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfordernden Software-User-Agents 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 Anforderung zu bearbeiten.

Sicherheit

Cross-Origin-Embedder-Policy (COEP): Erlaubt einem Server, eine Einbettungsrichtlinie für ein bestimmtes Dokument zu deklarieren.
Cross-Origin-Opener-Policy (COOP): Verhindert, dass andere Domains ein Fenster öffnen/steuern.
Cross-Origin-Resource-Policy (CORP): Verhindert, dass andere Domains die Antwort der Ressourcen lesen, auf die dieser Header angewendet wird. Siehe auch denCORP-Erklärungsartikel.
Content-Security-Policy (CSP): Steuerung der Ressourcen, die der User-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only: Erlaubt Webentwicklern, mit Richtlinien zu experimentieren, indem sie deren Auswirkungen überwachen, aber nicht durchsetzen. Diese Verstoßberichte bestehen ausJSON-Dokumenten, die über eine HTTP-POST-Anfrage an die angegebene URI gesendet werden.
Expect-CTVeraltet: Ermöglicht es Websites, die Berichterstattung und Durchsetzung von Certificate Transparency zu aktivieren, um die Verwendung von für diese Website falsch ausgestellten Zertifikaten zu erkennen.
Permissions-Policy: Bietet einen Mechanismus, um die Nutzung von Browser-Funktionen im eigenen Frame einer Website und in<iframe>s, die sie einbettet, zu erlauben oder zu verweigern.
Reporting-EndpointsExperimentell: Antwortheader, der Website-Eigentümern erlaubt, 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 angibt, dass er erfolgreich dieupgrade-insecure-requests-Richtlinie handhaben kann.
X-Content-Type-Options: Deaktiviert MIME-Sniffing und zwingt den Browser, den imContent-Type 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 plattformübergreifende Richtliniendatei kann Clients, wie Adobe Acrobat oder Apache Flex (unter anderem), die Berechtigung geben, Daten über Domains hinweg zu verarbeiten, die andernfalls durch dieSame-Origin-Policy eingeschränkt wären.DerX-Permitted-Cross-Domain-Policies-Header überschreibt solche Richtliniendateien, sodass Clients weiterhin unerwünschte Anfragen blockieren.
X-Powered-By: Kann von Hostingumgebungen oder anderen Frameworks gesetzt werden und enthält Informationen über diese, ohne jedoch einen Nutzen für die Anwendung oder ihre Besucher zu bieten. Entfernen Sie diesen Header, um zu vermeiden, potenzielle Schwachstellen offenzulegen.
X-XSS-Protection: Aktiviert die Filterung von Cross-Site-Scripting.

Fetch-Metadaten-Anforderungsheader

Fetch-Metadaten-Anforderungsheader geben Informationen über den Kontext, aus dem die Anforderung stammt. Ein Server kann sie verwenden, um Entscheidungen darüber zu treffen, ob eine Anforderung basierend auf deren Herkunft und Nutzung der Ressource erlaubt werden sollte.

Sec-Fetch-Site: Gibt das Verhältnis zwischen dem Ursprungsinitiator einer Anforderung und dem Zielursprung an. Es ist ein strukturierter Header, dessen Wert ein Token mit möglichen Wertencross-site,same-origin,same-site undnone ist.
Sec-Fetch-Mode: Gibt den Modus der Anforderung an einen Server an. Es ist ein strukturierter Header, dessen Wert ein Token mit möglichen Wertencors,navigate,no-cors,same-origin undwebsocket ist.
Sec-Fetch-User: Zeigt an, ob eine Navigationsanforderung durch Benutzaktivierung ausgelöst wurde oder nicht. Es ist ein strukturierter Header, dessen Wert ein Boolean ist, also sind mögliche Werte?0 für falsch und?1 für wahr.
Sec-Fetch-Dest: Gibt das Ziel der Anforderung an. Es handelt sich um einen strukturierten Header, dessen Wert ein Token mit möglichen Wertenaudio,audioworklet,document,embed,empty,font,image,manifest,object,paintworklet,report,script,serviceworker,sharedworker,style,track,video,worker undxslt ist.

Die folgenden Anforderungsheader sind nichtstreng "Fetch-Metadaten-Anforderungsheader", geben jedoch ä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 steuern:

Sec-Purpose: Gibt den Zweck der Anforderung an, wenn der Zweck etwas anderes als eine sofortige Verwendung durch den User-Agent ist. Der Header hat derzeit einen möglichen Wert,prefetch, der angibt, dass die Ressource vorsorglich für eine mögliche zukünftige Navigation abgerufen wird.
Service-Worker-Navigation-Preload: Ein Anforderungsheader, der in einer vorab gestellten Anfrage gesendet wird, um eine Ressource beim Start des Serviceworkers zufetch(). Der Wert, der mitNavigationPreloadManager.setHeaderValue() festgelegt wird, kann verwendet werden, um einem Server mitzuteilen, dass eine andere Ressource als bei einem normalenfetch()-Vorgang zurückgegeben werden soll.

Fetch-Speicherzugriffsheader

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

Sec-Fetch-Storage-Access: Gibt den "Speicherzugriffsstatus" für den aktuellen Abrufkontext an, der einer vonnone,inactive oderactive sein wird.Der Server kann mitActivate-Storage-Access antworten, um den Browser aufzufordern, eineinactive-Berechtigung zu aktivieren und die Anforderung erneut zu versuchen, oder um eine Ressource mit Zugriff auf ihre Drittanbieter-Cookies zu laden, wenn der Statusactive ist.
Activate-Storage-Access: Wird als Antwort aufSec-Fetch-Storage-Access verwendet, um anzuzeigen, dass der Browser eine bestehende Berechtigung für sicheren Zugriff aktivieren und die Anforderung mit Cookies erneut versuchen oder eine Ressource mit Cookie-Zugriff laden kann, wenn bereits eine aktivierte Berechtigung besteht.

Server-gesendete Ereignisse

Reporting-Endpoints: Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser Warn- und Fehlerberichte senden soll, wenn dieReporting API verwendet wird.
Report-ToVeraltet Nicht standardisiert: Antwortheader, der verwendet wird, um Serverendpunkte anzugeben, an die der Browser Warn- und Fehlerberichte senden soll, wenn die Reporting API verwendet wird.

Transfer-Codierung

Transfer-Encoding: Gibt die Form der Kodierung an, die zum sicheren Übertragen der Ressource an den Benutzer verwendet wird.
TE: Gibt die Übertragungskodierungen an, die der User Agent akzeptieren kann.
Trailer: Ermöglicht es dem Absender, zusätzliche Felder am Ende einer fragmentierten Nachricht einzufügen.

WebSockets

Header, die von derWebSockets-API imWebSocket-Handschlag verwendet werden:

Sec-WebSocket-Accept: Antwortheader, der anzeigt, dass der Server bereit ist, auf eine WebSocket-Verbindung zu aktualisieren.
Sec-WebSocket-Extensions: In Anfragen gibt dieser Header die von der Client-Unterstützung bevorzugten WebSocket-Erweiterungen an.In Antworten gibt er an, welche Erweiterung der Server aus den Präferenzen des Clients ausgewählt hat.
Sec-WebSocket-Key: Anforderungsheader, der einen Schlüssel enthält, der bestätigt, dass der Client explizit die Öffnung einesWebSocket beabsichtigt.
Sec-WebSocket-Protocol: In Anfragen gibt dieser Header die vom Client unterstützten Subprotokolle in bevorzugter Reihenfolge an.In Antworten gibt er an, welches Subprotokoll der Server aus den Präferenzen des Clients ausgewählt hat.
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.

Andere

Alt-Svc: Wird verwendet, um alternative Möglichkeiten anzugeben, diesen Dienst zu erreichen.
Alt-Used: Wird verwendet, um den in Gebrauch befindlichen alternativen Dienst 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, ein 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 soll, bevor er eine Folgetanfrage stellt.
Server-Timing: Kommuniziert eine oder mehrere Metriken und Beschreibungen für den jeweiligen Anfrage-Antwort-Zyklus.
Service-Worker: In Abrufen für die Skriptressource eines Serviceworkers enthalten.Dieser Header hilft Administratoren, Anfragen von Serviceworker-Skripten zu protokollieren, um Überwachungszwecke zu dienen.
Service-Worker-Allowed: Wird verwendet, um diePfadeinschränkung aufzuheben, indem dieser Header in derAntwort des Serviceworker-Skripts eingeschlossen wird.
SourceMap: Verlinkt auf eineSource Map, sodass Debugger durch den originalen Quellcode anstelle des generierten oder transformierten Codes navigieren können.
Upgrade: Dieser HTTP/1.1 (nur) Header kann verwendet werden, um eine bereits bestehende Client/Server-Verbindung zu einem anderen Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Beispielsweise kann es verwendet werden, um eine Verbindung von HTTP 1.1 zu HTTP 2.0 oder eine HTTP- oder HTTPS-Verbindung in einen WebSocket zu aktualisieren.
Priority: Gibt einen Hinweis über die Priorität einer bestimmten Ressourcenanforderung auf einer bestimmten Verbindung.Der Wert kann in einer Anforderung gesendet werden, um die Client-Priorität anzuzeigen, oder in einer Antwort, wenn der Server die Anforderung neu priorisieren möchte.

Experimentelle Header

Attribution-Reporting-Header

DieAttribution Reporting API ermöglicht es Entwicklern, Konversionen zu messen – beispielsweise wenn ein Benutzer auf eine in einer Website eingebettete Anzeige klickt und dann das Produkt auf der Website des Anbieters kauft – und dann Berichte über diese Konversionen abrufbar zu machen. Dies geschieht ohne Verwendung von Drittanbieter-Tracking-Cookies, stattdessen werden verschiedene Header verwendet, umQuellen undTrigger zu registrieren, die auf eine Konversion hinweisen.

Attribution-Reporting-Eligible: Wird verwendet, um anzugeben, dass die Antwort, die der aktuellen Anfrage entspricht, berechtigt ist, an einem Attribution-Reporting teilzunehmen, indem entweder eine Attributionsquelle oder ein Trigger registriert wird.
Attribution-Reporting-Register-Source: Wird als Teil einer Antwort auf eine Anfrage mit einemAttribution-Reporting-Eligible Header eingeschlossen, um eine Attributionsquelle zu registrieren.
Attribution-Reporting-Register-Trigger: Wird als Teil einer Antwort auf eine Anfrage mit einemAttribution-Reporting-Eligible Header eingeschlossen, um einen Attributionstrigger zu registrieren.

Client-Hints

HTTPClient Hints sind eine Reihe von Anforderungsheadern, die nützliche Informationen über den Client wie Gerätetyp und Netzbedingungen bereitstellen und es Servern erlauben, zu optimieren, was für diese Bedingungen bereitgestellt wird.

Server fordern proaktiv die vom Client gewünschten Client-Hint-Header an, indem sieAccept-CH verwenden. Der Client kann dann wählen, ob er die angeforderten Header in nachfolgenden Anforderungen einschließt.

Accept-CH: Server können Unterstützung für Client Hints mit demAccept-CH-Headerfeld oder einem entsprechenden HTML-<meta>-Element mithttp-equiv-Attribut bewerben.
Critical-CHExperimentell: Server verwendenCritical-CH zusammen mit Accept-CH, um anzugeben, dass akzeptierte Client Hints auchkritische Client Hints sind.

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

User-Agent-Client-Hints

DieUser-Agent-Client-Hints sind Anforderungsheader, die Informationen über den User-Agent, die darauf laufende Plattform/Architektur sowie Benutzereinstellungen auf dem User-Agent oder der Plattform bereitstellen:

Sec-CH-UAExperimentell: Marke und Version des User Agents.
Sec-CH-UA-ArchExperimentell: Plattformarchitektur des User Agents.
Sec-CH-UA-BitnessExperimentell: Bitanzahl der zugrunde liegenden CPU-Architektur des User Agents (zum Beispiel "64" Bit).
Sec-CH-UA-Form-FactorsExperimentell: Formfaktoren des User Agents, die beschreiben, wie der Benutzer mit dem User-Agent interagiert.
Sec-CH-UA-Full-VersionVeraltet: Vollständiger Versionsstring des User Agents.
Sec-CH-UA-Full-Version-ListExperimentell: Vollständige Version für jede Marke in der Markenliste des User Agents.
Sec-CH-UA-MobileExperimentell: Der User Agent läuft auf einem mobilen Gerät oder bevorzugt im Allgemeinen eine "mobile" Benutzererfahrung.
Sec-CH-UA-ModelExperimentell: Gerätemodell des User Agents.
Sec-CH-UA-PlatformExperimentell: Betriebssystem/Plattform des User Agents.
Sec-CH-UA-Platform-VersionExperimentell: Betriebssystemversion des User Agents.
Sec-CH-UA-WoW64Experimentell: Ob das User-Agent-Binary im 32-Bit-Modus auf 64-Bit-Windows läuft oder nicht.
Sec-CH-Prefers-Color-SchemeExperimentell: Farb-Schema-Präferenz des Benutzers zwischen dunkel und hell.
Sec-CH-Prefers-Reduced-MotionExperimentell: Präferenz des Benutzers, weniger Animationen und Inhaltsverschiebungen zu sehen.
Sec-CH-Prefers-Reduced-TransparencyExperimentell: Gibt an, dass die Präferenz des Benutzers für reduzierte Transparenz im User Agent besteht.

Hinweis:User-Agent-Client-Hints sind innerhalb von fenced frames nicht verfügbar, da sie aufBerechtigungsrichtlinien delegiert werden, was zur Datenexfiltration verwendet werden könnte.

Geräte- und responsiven Bild-Client-Hints

Sec-CH-Device-MemoryExperimentell: Ungefähre Menge an verfügbarem Arbeitsspeicher des Clients. Dies ist Teil der Device Memory API.
Sec-CH-DPRExperimentell: Anforderungsheader, der die Pixelanzahl pro Zoll (device pixel ratio) des Client-Geräts angibt (die Anzahl der physischen Gerätepixel für jedesCSS-Pixel).
Sec-CH-Viewport-HeightExperimentell: Anforderungsheader, der die Höhe des Layout-Viewports des Clients in CSS-Pixeln angibt.
Sec-CH-Viewport-WidthExperimentell: Anforderungsheader, der die Breite des Layout-Viewports des Clients in CSS-Pixeln angibt.
Sec-CH-WidthExperimentell: Anforderungsheader, der die Breite des Bildes in CSS-Pixeln bietet.

Veraltete Geräte- und responsiven Bild-Client-Hints

Device-MemoryVeraltet Nicht standardisiert: Standardisiert als Sec-CH-Device-Memory
DPRVeraltet Nicht standardisiert: Standardisiert als Sec-CH-DPR
Viewport-WidthVeraltet Nicht standardisiert: Standardisiert als Sec-CH-Viewport-Width
WidthVeraltet Nicht standardisiert: Standardisiert als Sec-CH-Width

Netzwerk-Client-Hints

Netzwerk-Client-Hints erlauben einem Server, auszuwählen, welche Informationen basierend auf der Benutzerwahl und Netzwerkbandbreite sowie Latenz gesendet werden.

DownlinkExperimentell: Ungefährer Wert für die Bandbreite der Verbindung des Clients zum Server in Mbit/s. Dies ist Teil der Network Information API.
ECTExperimentell: Der effektive Verbindungstyp ("Netzwerkprofil"), das die Latenz und Bandbreite der Verbindung am besten beschreibt. Dies ist Teil derNetwork Information API.
RTTExperimentell: Application Layer Round Trip Time (RTT) in Millisekunden, inklusive der Serververarbeitungszeit. Dies ist Teil der Network Information API.
Save-DataExperimentell: Ein Stringon, der die Präferenz des User Agents für geringeren Datenverbrauch angibt.

Transport von Kompressionswörterbüchern

Transport von Kompressionswörterbüchern ist eine Möglichkeit, ein gemeinsames Kompressionswörterbuch zu verwenden, um die Transportgröße von HTTP-Antworten zu verringern, anstatt das Standard-Statik-Wörterbuch in derBrotli-Kompression oder derZstandard-Kompression zu verwenden.

Available-DictionaryExperimentell: Ein Browser kann diesen Anforderungsheader verwenden, um das beste Wörterbuch anzugeben, das er für den Server zur Kompression hat.
Dictionary-IDExperimentell: Verwendet, wenn ein Browser bereits ein Wörterbuch für eine Ressource verfügbar hat, und der Server eineid für das Wörterbuch imUse-As-Dictionary-Header bereitstellt.Anfragen für Ressourcen, die das Wörterbuch verwenden können, haben einenAvailable-Dictionary-Header und die serverbereitgestellte Wörterbuch-id imDictionary-ID-Header.
Use-As-DictionaryExperimentell: Listet die übereinstimmenden Kriterien auf, für die das Wörterbuch zukünftig verwendet werden kann.

Privatsphäre

DNTVeraltet Nicht standardisiert: Anforderungsheader, der die Benutzerpräferenz zum Tracking (Do Not Track) angibt.Inzwischen durch Global Privacy Control (GPC) abgelöst, das Servern mithilfe des Sec-GPC-Headers kommuniziert wird und für Clients übernavigator.globalPrivacyControl zugänglich ist.
TkVeraltet Nicht standardisiert: Antwortheader, der den Tracking-Status angibt, der auf die entsprechende Anforderung angewendet wurde. Wird in Verbindung mit DNT verwendet.
Sec-GPCNicht standardisiert Experimentell: Gibt an, ob der Benutzer einer Website oder einem Dienst zustimmt, ihre persönlichen Informationen an Dritte zu verkaufen oder zu teilen.

Sicherheit

Origin-Agent-ClusterExperimentell: Antwortheader, der verwendet wird, um anzugeben, dass das zugehörige Document in einerorigin-basiertenAgenten-Cluster platziert werden soll.Diese Isolation ermöglicht es Benutzer-Agents, implementierungsspezifische Ressourcen für Agenten-Cluster, wie Prozesse oder Threads, effizienter zuzuweisen.

Server-gesendete Ereignisse

NELExperimentell: Definiert einen Mechanismus, der Entwicklern ermöglicht, eine Netzfehlerberichtspolitik zu deklarieren.

Topics API

Die Topics API bietet einen Mechanismus, mit dem Entwickler Anwendungsfälle wie interessenbasierte Werbung (IBA) implementieren können. Weitere Informationen finden Sie in derDokumentation zur Topics API.

Observe-Browsing-TopicsExperimentell Nicht standardisiert: Antwortheader, der verwendet wird, um Themen von Interesse zu kennzeichnen, die aus der URL der aufrufenden Website abgeleitet wurden und in der Antwort auf eine Anfrage beobachtet werden, die durch ein Feature, das die Topics API ermöglicht, generiert wurde.
Sec-Browsing-TopicsExperimentell Nicht standardisiert: Anforderungsheader, der die ausgewählten Themen für den aktuellen Benutzer zusammen mit der zugehörigen Anfrage sendet, die von einer Ad-Tech-Plattform verwendet werden, um eine personalisierte Anzeige auszuwählen.

Andere

Accept-SignatureExperimentell: Ein Client kann das Accept-Signature-Headerfeld senden, um die Absicht auszudrücken, eventuelle verfügbare Signaturen zu nutzen, und anzugeben, welche Arten von Signaturen unterstützt werden.
Early-DataExperimentell: Gibt an, dass die Anforderung in TLS-Offline-Daten übermittelt wurde.
Idempotency-KeyExperimentell: Bietet einen eindeutigen Schlüssel fürPOST- undPATCH-Anfragen und ermöglicht es, dass sie idempotent gemacht werden.
Set-LoginExperimentell: Antwortheader, gesendet von einem föderierten Identitätsanbieter (IdP), um dessen Anmeldestatus festzulegen, was bedeutet, ob Benutzer im aktuellen Browser beim IdP angemeldet sind oder nicht.Dies wird vom Browser gespeichert und von der FedCM-API verwendet.
SignatureExperimentell: Das Signature-Headerfeld übermittelt eine Liste von Signaturen für einen Austausch, jede begleitet von Informationen darüber, wie Autorität bestimmt und die Signatur aktualisiert wird.
Signed-HeadersExperimentell: Das Signed-Headers-Headerfeld identifiziert eine geordnete Liste von Antwort-Headerfeldern, die in eine Signatur einbezogen werden sollen.
Speculation-RulesExperimentell: 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 Spekulationsregelset des Dokuments hinzugefügt.
Sec-Speculation-TagsExperimentell: Enthält einen oder mehrere Tag-Werte der Spekulationsregeln, die zur Spekulation geführt haben, sodass ein Server erkennen kann, welche Regel(n) eine Spekulation verursacht haben, und möglicherweise blockieren kann.
Supports-Loading-ModeExperimentell: Wird von einem Navigationstarget gesetzt, um die Verwendung verschiedener höher riskanter Lademodi zu genehmigen. Zum Beispiel erfordert die plattformübergreifende gleichseitige Prerendering einenSupports-Loading-Mode-Wert voncredentialed-prerender.

Nicht-standardisierte Header

X-Forwarded-ForNicht standardisiert: Identifiziert die ursprüngliche IP-Adresse eines Clients, der über einen HTTP-Proxy oder einen Lastausgleichsserver eine Verbindung zu einem Webserver herstellt.
X-Forwarded-HostNicht standardisiert: Identifiziert den ursprünglichen Host, den ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Lastausgleichsserver herzustellen.
X-Forwarded-ProtoNicht standardisiert: Identifiziert das Protokoll (HTTP oder HTTPS), das ein Client verwendet hat, um eine Verbindung zu Ihrem Proxy oder Lastausgleichsserver herzustellen.
X-DNS-Prefetch-ControlNicht standardisiert: Kontrolliert das DNS-Prefetching, eine Funktion, bei der Browser proaktiv DNS-Abfragen von sowohl Links durchführen, denen Benutzer möglicherweise folgen könnten, als auch von URLs für Elemente, auf die vom Dokument referenziert wird, einschließlich Bilder, CSS, JavaScript usw.
X-Robots-TagNicht standardisiert: Der X-Robots-Tag HTTP-Header wird verwendet, um anzuzeigen, wie eine Webseite in öffentlichen Suchmaschinenergebnissen indexiert werden soll. Der Header ist gleichbedeutend mit<meta name="robots">-Elementen.

Veraltete Header

PragmaVeraltet: Implementierungsspezifischer Header, der überall entlang der Anfrage-Antwort-Kette verschiedene Effekte haben kann. Wird zur Rückwärtskompatibilität mit HTTP/1.0 Caches verwendet, bei denen derCache-Control-Header noch nicht vorhanden ist.
WarningVeraltet: Allgemeine Warninformationen über mögliche Probleme.

Siehe auch

Help improve MDN

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