Was der Server beim Seitenaufruf erhält

Eine Netzwerkanfrage kann Verbindungsdaten, Header und gespeicherte Cookies übertragen, bevor die angeforderte Seite eigenes JavaScript ausführt. Ein Einwilligungsbanner macht eine bereits gesendete Anfrage nicht rückgängig. Daraus folgt jedoch weder eine Pflicht für jeden Header noch die Unvermeidbarkeit jeder späteren Datennutzung.

Die erste Anfrage ist nicht der gesamte Seitenaufbau

Die relevante Grenze liegt zwischen der Dokumentanfrage und dem anschließend durch dieses Dokument ausgeführten Code. Eine vorherige Seite, Erweiterung oder ein Service Worker kann bereits Code ausgeführt haben. Ein späterer fetch-Aufruf erzeugt eine weitere Anfrage und rekonstruiert nicht die ursprüngliche Navigation.

Eine allgemeine Reihenfolge aus Banner, Tag Manager und Statistik existiert nicht. Skripte können während des Ladens laufen; serverseitige Verarbeitung benötigt kein JavaScript. Frühere Einstellungen beeinflussen mögliche Übertragungen. Ein neu eingeblendeter Banner verändert keine bereits empfangenen Bytes.

Drei Header sind ein curl-Standard, kein HTTP-Minimum

Der bisherige Artikel nennt für September 2026 drei Header bei curl, elf bei einer Navigation und dreizehn bei fetch. Das sind historische Beispielzahlen, keine Browsergrenzen. Die ursprünglichen Browseraufzeichnungen lagen für eine unabhängige Kontrolle dieser Prüfung nicht vor.

Ein lokaler HTTP/1.1-Test bestätigte die curl-Standardfelder Host, User-Agent und Accept. Ohne User-Agent und Accept gelang weiterhin eine Anfrage mit ausschließlich Host. HTTP/1.1 verlangt Host; die beiden anderen Felder sind nicht für jede gültige Anfrage vorgeschrieben. HTTP/2 und HTTP/3 besitzen eigene Rahmen- und Pseudoheaderregeln.

Header beschreiben Kontext, keine bestätigte Person

Accept beschreibt akzeptierte Antwortformate; Accept-Language enthält Sprachpräferenzen. Eine Sprachliste allein bestätigt keine Identität und beziffert kein Wiedererkennungsrisiko. Einstellungen, Datenschutzfunktionen, Anfrageart und Zwischenstationen beeinflussen die Felder.

Sec-Fetch-Site, Sec-Fetch-Mode und Sec-Fetch-Dest beschreiben den Kontext. Sec-Fetch-User: ?1 kennzeichnet bei unterstützenden Browsern eine Navigation mit Nutzeraktivierung. Das beweist keine menschliche statt automatisierter Bedienung: Andere Programme können Header nachbilden, und Skripte können an einer aktivierten Navigation beteiligt sein.

Client Hints hängen von Unterstützung und Regeln ab

Unterstützende Chromium-Browser senden die grundlegenden Browserangaben (UA-Hints) für Marke und Version, Mobilstatus und Plattform üblicherweise über sichere Verbindungen. Das ist keine Zusage für jeden Browser oder jede eingebettete Umgebung.

Zusätzliche HTTP-Hints benötigen üblicherweise eine Anforderung über Accept-CH und bleiben von Browserregeln abhängig. Daneben existiert mit navigator.userAgentData.getHighEntropyValues() eine eigene JavaScript-Schnittstelle. Ein fehlender Accept-CH-Header beweist daher nicht, dass Skripte keine weiteren Angaben erhalten können.

Verbindungsdaten und zusätzliche Abfragen

Die empfangende Gegenstelle kennt den Netzwerkpartner. Dessen Adresse kann zu Proxy, VPN oder CDN gehören statt zum Endgerät. Reverse DNS sucht einen zu einer IP-Adresse hinterlegten Hostnamen. RDAP fragt Registrierungsdaten ab, etwa die für einen Adressbereich zuständige Organisation. Beide sind zusätzliche Abfragen. Die Ergebnisse sind keine vom Browser mitgeschickten Felder. Ein Netzinhaber beweist weder einen Privatanschluss noch eine bestimmte Person.

Bei HTTPS stehen ausgehandelte TLS-Angaben zur Verfügung, soweit der Server diese bereitstellt. Unverschlüsseltes HTTP besitzt kein TLS. Verbindungen können wiederverwendet werden; TLS-1.3-Frühdaten bilden eine Ausnahme zur Behauptung, jede Anfrage folge einem frisch abgeschlossenen Handshake. Ein TLS-beendendes CDN besitzt eine gesonderte Verbindung zum Ursprung, gegebenenfalls mit anderen Parametern oder ohne TLS.

Was der Verbindungsspiegel tatsächlich misst

Das verlinkte Werkzeug ruft seine API per fetch auf und zeigt diese API-Anfrage. Die Auswertung beobachtet 38 benannte Header, begrenzt angezeigte Werte auf 500 Zeichen und gibt Cookie- sowie Authorization-Werte nicht roh aus. Cookie-Namen erscheinen gesondert. Die Gesamtzahl kann größer als die angezeigte Auswahl sein.

Der Endpunkt führt für geeignete öffentliche Adressen Reverse DNS aus; RDAP folgt erst auf die gesondert angeforderte Netzabfrage. Außerdem wird ein adressbezogener Anfragezähler geführt. Das Werkzeug bildet somit nicht lediglich passiv den ersten Seitenabruf ab. Angaben aus Proxy-Headern benötigen eine vertrauenswürdige Proxykonfiguration, bevor daraus eine Clientadresse abgeleitet wird.

Datenschutzsignale und vorhandene Cookies

Sec-GPC: 1 übermittelt eine Präferenz gegen bestimmte Verkaufs-, Weitergabe- und kontextübergreifende Werbenutzungen. Das Signal verbietet technisch nicht jede Datenerhebung. Die ältere DNT-Spezifikation definiert sowohl 1 als auch 0. DNT bedeutet daher nicht grundsätzlich Nein. Ein fehlendes Signal beweist keine Einwilligung.

Vorhandene Cookies können bereits vor dem Seitencode bei passenden Anfragen mitgesendet werden, abhängig von Geltungsbereich und Browserbeschränkungen. Auch der erste Aufruf einer bestimmten URL kann Cookies aus einem anderen passenden Bereich enthalten. localStorage wird nicht automatisch als HTTP-Header übertragen; ein Skript kann später einen ausgelesenen Wert senden.

Verbindungsspiegel

curl -q --http1.1 -sv https://example.com/ -o /dev/null 2>&1 | grep '^>'