HTTP Client Hints

Ü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. Zusätzlich sendet er dem Server eine Standardsatz von Sec-CH-UA-*-Headern; dieser Satz von Hinweisen wird als die niedriges Entropie-Hinweise bezeichnet. Ein Android-Gerät würde zum Beispiel etwas wie das Folgende 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 folgende Informationen:

   • Sec-CH-UA: Die Hauptbrowser-Version und andere damit verbundene Marken.
   • Sec-CH-UA-Platform: Die Plattform.
   • Sec-CH-UA-Mobile: Ein Boolescher Wert, der anzeigt, ob der Browser auf einem mobilen Gerät (?1) oder nicht (?0) läuft.

3. Der Server kann ankündigen, dass er Client Hints unterstützt und zusätzliche Client Hints anfordern, indem er den Accept-CH Antwort-Header verwendet, der eine durch Kommata getrennte 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
   

   Der Standardsatz 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 Nutzer mit dem User-Agent interagiert — die Bildschirmgröße, Steuerungen etc.

4. Wenn der Browser dazu berechtigt ist, wird er die angeforderten Header bei allen nachfolgenden Anfragen senden, bis der Browser oder der Tab geschlossen wird. Unser Beispiel-Android-Telefon könnte 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 außerdem relativ datenschutzfreundlich, da es dem Client überlassen ist, zu entscheiden, welche Informationen sicher geteilt werden können.

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

Caching und Client Hints

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

Vary: Accept, Width, ECT

Es kann bevorzugt werden, Vary nicht anzugeben oder eine andere Strategie für Hinweis-Header zu verwenden, bei denen sich der Wert häufig ändert, da dies die Ressource effektiv nicht zwischenspeicherbar macht. (Ein neuer Cache-Eintrag wird für jeden eindeutigen Wert erstellt.) Dies gilt insbesondere für Netzwerk-Client-Hints wie Downlink und RTT. Weitere Informationen finden Sie unter HTTP Caching > Vary.

Lebensdauer der Hints

Ein Server gibt die Client-Hints-Header an, die er interessiert erhält, im Accept-CH Antwort-Header an. Der User-Agent fügt die angeforderten Client-Hints-Header, oder zumindest die Teilmenge, die er mit diesem Server teilen möchte, allen nachfolgenden Anfragen in der aktuellen Browsersitzung hinzu.

Mit anderen Worten, die Anforderung für eine spezifische Reihe von Hints läuft nicht ab, bis der Browser heruntergefahren wird.

Ein Server kann die Menge der Client Hints, die er zu erhalten wünscht, ändern, indem er den Accept-CH Antwort-Header mit einer neuen Liste erneut sendet. Zum Beispiel würde er, um keine Hints mehr anzufordern, Accept-CH mit einer leeren Liste senden.

Niedriges Entropie-Hints

Client Hints werden allgemein in hoch und niedriges Entropie-Hints unterteilt. Die niedrigen Entropie-Hints sind solche, die nicht viele Informationen preisgeben, die dazu verwendet werden könnten, einen Nutzer zu fingerprinten. Sie können standardmäßig bei jeder Client-Anfrage gesendet werden, unabhängig vom Accept-CH Antwort-Header des Servers, abhängig von der Berechtigungsrichtlinie. Die niedrigen Entropie-Hints sind:

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

Hoches Entropie-Hints

Die hoch Entropie-Hints sind solche, die potenziell mehr Informationen preisgeben können, die für ein Benutzer-Fingerprint verwendet werden könnten, und daher auf eine Weise gesteuert werden, dass der User-Agent entscheiden kann, ob sie bereitgestellt werden. Die Entscheidung kann auf Benutzerpräferenzen, einer Berechtigungsanfrage oder einer Berechtigungsrichtlinie basieren. Alle Client Hints, die keine niedrigen Entropie-Hints sind, werden als hoch Entropie-Hints betrachtet.

Kritische Client Hints

Ein kritischer Client Hint ist einer, bei dem die Anwendung der Antwort die gerenderte Seite erheblich verändern könnte, möglicherweise auf eine Weise, die störend ist oder die Benutzerfreundlichkeit beeinträchtigen könnte, und daher vor dem Rendern des Inhalts angewendet werden muss. Beispielsweise wird Sec-CH-Prefers-Reduced-Motion häufig als kritischer Hinweis behandelt, da er das Verhalten von Animationen deutlich beeinflussen könnte und ein Benutzer, der diese Präferenz wählt, sie gesetzt haben muss.

Ein Server kann den Critical-CH Antwort-Header zusammen mit Accept-CH verwenden, um anzugeben, dass ein akzeptierter Client-Hint auch ein kritischer Client-Hint ist (ein Header in Critical-CH muss auch in Accept-CH erscheinen). User Agents, die eine Antwort mit Critical-CH erhalten, müssen überprüfen, ob die angegebenen kritischen Header in der ursprünglichen Anfrage gesendet wurden. Wenn nicht, wird der User Agent die Anfrage erneut versuchen, anstatt die Seite zu rendern. Dieser Ansatz stellt sicher, dass Client-Präferenzen, die mit kritischen Client-Hints gesetzt wurden, immer verwendet werden, auch wenn sie nicht in der ersten Anfrage enthalten sind oder 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 anzugeben, dass Sec-CH-Prefers-Reduced-Motion als kritischer Client-Hint betrachtet 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, wiederholt der Client automatisch die Anfrage — diesmal sagt er dem Server über Sec-CH-Prefers-Reduced-Motion, 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 für die Seite gewünscht sind, während Critical-CH nur die Teilmenge von Werten anfordert, die unbedingt beim Laden der Seite erforderlich sind.

Hint-Typen

User-Agent-Client-Hints

User-Agent (UA) Client-Hint-Header ermöglichen es einem Server, Antworten basierend auf dem User-Agent (Browser), Betriebssystem und Gerät zu variieren. Für eine Liste der Sec-CH-UA-*-Header siehe User-Agent-Client-Hints-Header.

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

Client-Hints für Benutzerpräferenzen-Medienmerkmale

Client-Hints für Benutzerpräferenzen-Medienmerkmale ermöglichen es einem Server, Antworten basierend auf den Präferenzen eines User-Agents für CSS-Medienmerkmale wie Farbschema oder reduzierte Bewegung zu variieren. Zu den Headern gehören: Sec-CH-Prefers-Reduced-Motion, Sec-CH-Prefers-Color-Scheme.

Geräte-Client-Hints

Geräte-Client-Hints ermöglichen es einem Server, Antworten basierend auf Gerätecharakteristika einschließlich verfügbarem Speicher und Bildschirmeigenschaften zu variieren. Zu den Headern gehören: Device-Memory, Width, Viewport-Width.

Netzwerk-Client-Hints

Netzwerk-Client-Hints ermöglichen es einem Server, Antworten basierend auf der Wahl des Nutzers, der Netzwerkbandbreite und der Latenz zu variieren. Zu den Headern gehören: Save-Data, Downlink, ECT, RTT.

Verwendung von Client-Hints für Responsive Design

Es ist möglich, Client-Hints für Responsive Design zu verwenden, um beispielsweise zu erkennen, ob ein mobiles Gerät oder ein Tablet Ihre Website rendert.

Ein Android-Telefon würde die folgenden Standard-Client-Hints 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 zu bestimmen, ob das Gerät ein mobiles Gerät ist oder nicht. Für hardware-spezifische Anwendungsfälle können der Gerätename und das Formfaktor über die hoch Entropie-Hints Sec-CH-UA-Model und Sec-CH-UA-Form-Factors angefordert werden.

Für viele Responsive-Design-Anforderungen können Media Queries bequemer und flexibler sein. Es kann jedoch Fälle geben, in denen Sie keine Kontrolle über die individuellen Stylesheets einer Website haben und das ausgelieferte Stylesheet basierend auf der Gerätesignatur oder einer Art von Benutzerpräferenz variieren müssen. Es gibt Client-Hints, die einige der „Benutzerpräferenz“-Media Queries spiegeln, wie Sec-CH-Prefers-Color-Scheme, Sec-CH-Prefers-Reduced-Motion und Sec-CH-Prefers-Reduced-Transparency.

Siehe auch

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