HTTP-Client-Hinweise

Übersicht

1. Wenn der Browser zum ersten Mal eine Anfrage zum Laden einer Webseite stellt, sendet er den User-Agent-Header an den Server.

2. Darüber hinaus sendet er dem Server eine Standardgruppe von Sec-CH-UA-*-Headern; diese Gruppe von Hinweisen wird als die Hints mit geringer Entropie bezeichnet. Ein Android-Gerät würde zum Beispiel etwas wie dieses senden:

   http

   Sec-CH-UA: "Google Chrome";v="143", "Chromium";v="143", "Not A(Brand";v="24" Sec-CH-UA-Platform: "Android" Sec-CH-UA-Mobile: ?1 

   Diese Header liefern die folgenden Informationen:

   • Sec-CH-UA: Die Hauptversion des Browsers und andere damit verbundene Marken.
   • Sec-CH-UA-Platform: Die Plattform.
   • Sec-CH-UA-Mobile: Ein Boolean, der angibt, ob der Browser auf einem mobilen Gerät läuft (?1) oder nicht (?0).

3. Der Server kann ankündigen, dass er Client-Hinweise unterstützt und zusätzliche Client-Hinweise anfordern, indem er den Accept-CH-Antwortheader verwendet, der eine kommagetrennte Liste der zusätzlichen Header enthält, die er in nachfolgenden Anfragen erhalten möchte. Zum Beispiel:

   http

   Accept-CH: Sec-CH-UA-Model, Sec-CH-UA-Form-Factors 

   Die Standardgruppe von Headern wird immer gesendet; in diesem Fall haben wir auch angefordert:

   • Sec-CH-UA-Model: Das Gerätemodell, auf dem die Plattform läuft.
   • Sec-CH-UA-Form-Factors: Die Formfaktoren des Geräts, die angeben, wie der Benutzer mit dem User-Agent interagiert — die Bildschirmgröße, Steuerungen usw.

4. Wenn es dem Browser erlaubt ist, sendet er die angeforderten Header in allen nachfolgenden Anfragen, bis der Browser oder Tab geschlossen wird. Zum Beispiel könnte unser Beispiel-Android-Handy mit nachfolgenden Anfragen die folgenden aktualisierten Header senden:

   http

   Sec-CH-UA: "Google Chrome";v="143", "Chromium";v="143", "Not A(Brand";v="24" Sec-CH-UA-Platform: "Android" Sec-CH-UA-Mobile: ?1 Sec-CH-UA-Model: "Pixel 9" Sec-CH-UA-Form-Factors: "Mobile" 

Dieser Ansatz ist effizient, da der Server nur die Informationen anfordert, die er sinnvoll verarbeiten kann. Er ist auch relativ "datenschutzwahrend", da es dem Client überlassen bleibt, zu entscheiden, welche Informationen er sicher teilen kann.

<meta http-equiv="Accept-CH" content="Width, Downlink, Sec-CH-UA" /> 

Caching und Client-Hinweise

Client-Hinweise, die bestimmen, welche Ressourcen in Antworten gesendet werden, sollten im Allgemeinen auch im Vary-Header der betroffenen Antwort enthalten sein. Dies stellt sicher, dass für jeden unterschiedlichen Wert des Hinweis-Headers eine andere Ressource zwischengespeichert wird.

Vary: Accept, Width, ECT 

Es kann bevorzugt werden, Vary nicht zu spezifizieren oder eine andere Strategie für Client-Hinweis-Header zu verwenden, bei denen sich der Wert häufig ändert, da dies die Ressource effektiv nicht zwischenzuspeichern macht. (Ein neuer Cache-Eintrag wird für jeden einzigartigen Wert erstellt.) Dies gilt insbesondere für Netzwerkclient-Hinweise wie Downlink und RTT. Für weitere Informationen siehe HTTP-Caching > Vary.

Hinweis-Lebensdauer

Ein Server gibt die Client-Hinweis-Header an, an denen er interessiert ist, indem er den Accept-CH-Antwortheader verwendet. Der User-Agent fügt die angeforderten Client-Hinweis-Header oder zumindest den Teil, den er mit diesem Server teilen möchte, allen nachfolgenden Anfragen in der aktuellen Browsersitzung hinzu.

Mit anderen Worten, die Anfrage nach einer bestimmten Gruppe von Hinweisen läuft nicht ab, bis der Browser heruntergefahren wird.

Ein Server kann die Gruppe der Client-Hinweise, an der er interessiert ist, ersetzen, indem er den Accept-CH-Antwortheader mit einer neuen Liste erneut sendet. Zum Beispiel, um keine Hinweise mehr anzufordern, würde er Accept-CH mit einer leeren Liste senden.

Hints mit geringer Entropie

Client-Hinweise werden grob in Hints mit hoher und geringer Entropie unterteilt. Die Hints mit geringer Entropie sind diejenigen, die nicht viel Informationen preisgeben, die zum Fingerprinting eines Benutzers verwendet werden könnten. Sie können standardmäßig bei jeder Client-Anfrage gesendet werden, unabhängig vom Accept-CH-Antwortheader des Servers, abhängig von der Berechtigungsrichtlinie. Hinweise mit geringer Entropie sind:

• Save-Data,
• Sec-CH-UA,
• Sec-CH-UA-Mobile, und
• Sec-CH-UA-Platform.

Hints mit hoher Entropie

Die Hints mit hoher Entropie sind jene, die potenziell mehr Informationen preisgeben können, die zum User-Fingerprinting genutzt werden können, und sind daher so gestaltet, dass der User-Agent die Entscheidung treffen kann, ob sie bereitgestellt werden. Die Entscheidung kann auf Nutzerpräferenzen, eine Berechtigungsanfrage oder eine Berechtigungsrichtlinie basieren. Alle Client-Hinweise, die keine Hints mit geringer Entropie sind, gelten als Hints mit hoher Entropie.

Kritische Client-Hinweise

Ein kritischer Client-Hinweis ist einer, bei dem die Anwendung der Antwort die gerenderte Seite signifikant verändern kann, möglicherweise in einer störenden Weise oder die Benutzerfreundlichkeit beeinträchtigt, und daher vor der Darstellung des Inhalts angewendet werden muss. Zum Beispiel wird Sec-CH-Prefers-Reduced-Motion häufig als kritischer Hinweis behandelt, da es das Verhalten von Animationen deutlich beeinflussen könnte, und weil ein Benutzer, der diese Präferenz wählt, erwartet, dass sie eingestellt wird.

Ein Server kann den Critical-CH-Antwortheader zusammen mit Accept-CH verwenden, um anzugeben, dass ein akzeptierter Client-Hinweis auch ein kritischer Client-Hinweis ist (ein Header in Critical-CH muss auch in Accept-CH erscheinen). User-Agents, die eine Antwort mit Critical-CH erhalten, müssen prüfen, ob die angegebenen kritischen Header in der ursprünglichen Anfrage gesendet wurden. Wenn nicht, wird der User-Agent die Anfrage erneut stellen, anstatt die Seite zu rendern. Dieser Ansatz stellt sicher, dass Client-Präferenzen, die mithilfe kritischer Client-Hinweise festgelegt wurden, immer verwendet werden, auch wenn sie nicht in der ersten Anfrage enthalten sind oder wenn sich die Serverkonfiguration ändert.

Zum Beispiel sagt der Server in diesem Fall einem Client über Accept-CH, dass er Sec-CH-Prefers-Reduced-Motion akzeptiert, und Critical-CH wird verwendet, um zu spezifizieren, dass Sec-CH-Prefers-Reduced-Motion als kritischer Client-Hinweis angesehen wird:

HTTP/1.1 200 OK Content-Type: text/html Accept-CH: Sec-CH-Prefers-Reduced-Motion Vary: Sec-CH-Prefers-Reduced-Motion Critical-CH: Sec-CH-Prefers-Reduced-Motion 

Da Sec-CH-Prefers-Reduced-Motion ein kritischer Hinweis ist, der nicht in der ursprünglichen Anfrage enthalten war, wird der Client die Anfrage automatisch erneut stellen — diesmal dem Server mit Sec-CH-Prefers-Reduced-Motion mitteilend, dass er eine Benutzerpräferenz für reduzierte Bewegungsanimationen hat.

GET / HTTP/1.1 Host: example.com Sec-CH-Prefers-Reduced-Motion: "reduce" 

Zusammenfassend fordert Accept-CH alle Werte an, die Sie für die Seite benötigen, während Critical-CH nur die Teilmenge der Werte anfordert, die Sie beim Laden unbedingt benötigen, um die Seite richtig zu laden.

Hinweis-Typen

User-Agent-Client-Hinweise

User-Agent- (UA-) Client-Hinweisheader ermöglichen es einem Server, Antworten basierend auf dem User-Agent (Browser), Betriebssystem und Gerät zu variieren. Eine Liste der Sec-CH-UA-*-Header finden Sie unter User-Agent-Client-Hinweis-Header.

Client-Hinweise sind für JavaScript von Webseiten über die User-Agent-Client-Hinweise-API verfügbar.

Benutzerpräferenz-Media-Feature-Client-Hinweise

Benutzerpräferenz-Media-Feature-Client-Hinweise erlauben es einem Server, Antworten basierend auf den Präferenzen eines User-Agents für CSS-Medien-Features wie Farbthema oder reduzierte Bewegung zu variieren. Header schließen ein: Sec-CH-Prefers-Reduced-Motion, Sec-CH-Prefers-Color-Scheme.

Geräte-Client-Hinweise

Geräte-Client-Hinweise erlauben es einem Server, Antworten basierend auf Gerätecharakteristiken einschließlich verfügbarem Speicher und Bildschirmeigenschaften zu variieren. Header schließen ein: Sec-CH-Device-Memory, Sec-CH-DPR, Sec-CH-Viewport-Height, Sec-CH-Viewport-Width.

Netzwerk-Client-Hinweise

Netzwerk-Client-Hinweise erlauben es einem Server, Antworten basierend auf der Auswahl des Benutzers, der Netzwerkbandbreite und Latenzzeit zu variieren. Header schließen ein: Save-Data, Downlink, ECT, RTT.

Verwendung von Client-Hinweisen für responsives Design

Es ist möglich, Client-Hinweise für responsives Design zu verwenden, zum Beispiel um zu erkennen, ob ein mobiles Gerät oder ein Tablet Ihre Seite rendert.

Ein Android-Telefon würde die folgenden Standard-Client-Hinweise senden:

Sec-CH-UA: "Google Chrome";v="143", "Chromium";v="143", "Not A(Brand";v="24" Sec-CH-UA-Platform: "Android" Sec-CH-UA-Mobile: ?1 

Ein Android-Tablet hingegen würde die folgenden senden:

Sec-CH-UA: "Google Chrome";v="143", "Chromium";v="143", "Not A(Brand";v="24" Sec-CH-UA-Platform: "Android" Sec-CH-UA-Mobile: ?0 

Der Sec-CH-UA-Mobile-Header kann verwendet werden, um festzustellen, ob es sich bei dem Gerät um ein mobiles Gerät handelt oder nicht. Für hardware-spezifische Anwendungsfälle können der Gerätename und die Formfaktoren über die hochentropischen Hinweise Sec-CH-UA-Model und Sec-CH-UA-Form-Factors angefordert werden.

Für viele Bedürfnisse des responsiven Designs können Media Queries bequemer und flexibler sein. Es kann jedoch Fälle geben, in denen Sie keinen Zugriff auf die einzelnen Stylesheets einer Seite haben und das servierte Stylesheet basierend auf der Gerätesignatur oder einer Art Benutzerpräferenz variieren müssen. Es gibt Client-Hinweise, die einige der "Benutzerpräferenz"-Media Queries widerspiegeln, wie Sec-CH-Prefers-Color-Scheme, Sec-CH-Prefers-Reduced-Motion, und Sec-CH-Prefers-Reduced-Transparency.

Siehe auch

• Client-Hinweis-Header
• Vary HTTP-Header
• Client Hints Infrastructure
• User-Agent-Client-Hinweise API
• Verbesserung des Datenschutzes und der Entwicklererfahrung mit User-Agent-Client-Hinweisen auf developer.chrome.com (2020)
• Migration zu User-Agent-Client-Hinweisen auf web.dev (2021)