Zusammenfassung

  • No-Vary-Search erlaubt dem Origin, bestimmte Query-Schlüssel oder deren Reihenfolge bei der Cache-Zuordnung als unerheblich zu erklären. Frische, Validierung, Vary, Autorisierung und alle weiteren Bedingungen bleiben bestehen.
  • Die vollständige URL wird weder entfernt noch umgeschrieben. Eine falsche Erklärung kann einen Origin-Aufruf verhindern und in einem Shared Cache eine für einen anderen Kontext gespeicherte Antwort ausliefern.

Auf /dossier?id=31&utm_source=briefing folgt /dossier?utm_source=event&id=31. Die Anwendung weiß, dass die Quelle den Inhalt nicht verändert und die Reihenfolge egal ist. Für den Cache sind es zwei Target URIs. Ohne Erklärung muss er sie trennen; er darf Geschäftssemantik nicht aus ähnlichen Bodies oder freundlichen Parameternamen erraten.

draft-ietf-httpbis-no-vary-search-09 vom 17. August 2026 beschreibt diese Erklärung. Am 29. August ist es ein aktiver HTTPBIS-Internet-Draft mit Ziel Proposed Standard und IESG-Status „approved, announcement pending, AD follow-up“. Es ist noch kein RFC. Im IANA-Register der HTTP-Feldnamen steht No-Vary-Search noch nicht.

Der Status erlaubt kontrollierte Versuche, aber keine Behauptung eines fertigen Standards. Der Text belegt Grammatik und beabsichtigte Grenzen. Er belegt weder die konkrete Cache-Implementierung noch die Richtigkeit der Klassifikation.

Die Grundregel trennt exakt

RFC 9111 bindet Wiederverwendung an Methode, passende Target URI, die durch Vary benannten Request-Felder, Frische oder erfolgreiche Validierung und passende Cache Controls. Eine andere Query bedeutet gewöhnlich eine andere URI.

HTTP kann nicht wissen, ob account, token oder campaign Dekoration ist. Gleichbleibende Test-Bodies schließen nicht aus, dass ein Schlüssel Routing, Berechtigung, Abrechnung oder spätere Varianten beeinflusst.

Das neue Feld verändert nur die URI-Zuordnung. Es macht Veraltetes nicht frisch, hebt Vary nicht auf, macht eine private Antwort nicht öffentlich und gewährt keinen Zugriff. Nach der Query-Äquivalenz müssen alle übrigen RFC-9111-Prüfungen weiter bestehen.

Drei Schlüssel verteilen Verantwortung

Der Feldwert ist ein Dictionary nach RFC 9651. key-order ist Boolean. params nennt zu ignorierende Schlüssel; except nennt umgekehrt nur jene, die weiterhin variieren. Beide Listen dürfen nicht gemeinsam vorkommen.

Der Origin setzt das Feld, weil er die Anwendungssemantik besitzt. Ein Intermediär darf es nicht einfügen, löschen oder ändern, außer er handelt für diese Antwort als Origin. Eine aus Traffic-Mustern erzeugte CDN-Regel würde die Autorität an die Schicht verschieben, die den Zweck der Parameter am wenigsten kennt.

Fehler bleiben konservativ. Fehlende, ungültige oder widersprüchliche Werte führen zurück zu exakter Query und relevanter Reihenfolge. Treffer gehen verloren, nicht Trennung. Unbekannte Dictionary-Schlüssel werden ignoriert. Künftige Erweiterungen dürfen daher Äquivalenz nur ausweiten; eine Einschränkung braucht ein neues Feld, damit alte Empfänger nicht zu breit wiederverwenden.

Dekodierte Paare entscheiden

Äquivalenz überschreitet niemals Scheme, Host, Port oder Path. Innerhalb dieser Grenze parst eine nicht standardmäßige Konfiguration die Query nach dem WHATWG-Modell application/x-www-form-urlencoded, entfernt ignorierte Paare oder behält nur except, sortiert bei Bedarf nach Schlüssel und vergleicht Schlüssel plus Werte. Duplikate bleiben erhalten.

Percent Decoding, die Umwandlung von + in Leerzeichen und leere Segmente können sichtbar verschiedene Strings zusammenführen. Ungültiges UTF-8 kann als U+FFFD enden und verschiedene Bytes auf denselben Schlüssel abbilden. Unicode-Normalisierung findet hingegen nicht statt; NFC und NFD bleiben verschieden.

Signiert eine Anwendung die Originalbytes, nutzt ein Router die Duplikatreihenfolge oder bedeutet ein leerer Wert Einwilligung, ist diese Differenz sicherheitsrelevant. Der Draft erklärt das Feld für Queries außerhalb des Form-Modells als ungeeignet. RFC 6943 beschreibt das allgemeine Risiko unterschiedlicher Identifier-Vergleiche; hier bestimmt ein False Positive unmittelbar den ausgelieferten Body.

Der Cache darf ablehnen

Ein unterstützender Cache kann die erweiterte Zuordnung nutzen, muss es aber nicht. Er kann zuerst exakt suchen, einen vereinfachten Index aufbauen oder einen Kandidaten ablehnen. Der Origin stellt Wissen bereit; der Cache behält die lokale Entscheidung, weil er die Wiederverwendungsfolge trägt.

Widersprechen sich nichtleere Konfigurationen für denselben Host und Path, darf der Cache die mit neuerem Date bevorzugen, um zu konvergieren. Neu bedeutet nicht richtig. Eine falsche Regel kann die jüngste sein, und ein Rollout verteilt sie ungleich.

Auch die Invalidierung bleibt unverändert. Nach einer zustandsändernden Methode darf ein Cache äquivalente URIs mitinvalidieren, muss es aber nicht. Beim Lesen zusammengeführte Einträge können nach einem Schreiben unterschiedlich fortbestehen. Query-basierte Cache Buster versagen, wenn genau ihr Schlüssel ignoriert wird; content-adressierte Pfade sind eine getrennte, deutlichere Strategie.

Kein Parameter wird unsichtbar

Der Browser zeigt die ganze URL und kann sie in der History speichern. CDN, Proxy, Logs und Analytics erhalten die Parameter weiterhin. No-Vary-Search steuert Cache Matching, nicht Datenschutzbereinigung, Redirect oder Canonical URL.

Ein Private Cache kann einen späteren Trackingwert lokal beantworten und dem Origin Arbeit ersparen. Ein Shared Cache sieht den Request trotzdem und erweitert bei einer Fehlklassifikation den Empfängerkreis einer gespeicherten Antwort.

Schlüssel für Identität, Autorisierung, Signaturprüfung, Einwilligung, Routing, Audit, Abrechnung, Widerruf oder andere Voraussetzungen sicherer Wiederverwendung dürfen nie ignoriert werden. Gleiche Pixel bedeuten nicht gleiches Zugriffsrecht. Gleicher HTML-Body bedeutet nicht, dass ein Pflichtprotokoll entfallen darf.

Im schlimmsten Shared-Cache-Fall erhält Alice eine für Bob geholte Darstellung. private, Partitionierung und korrekte Controls bleiben notwendig, entschuldigen aber keine falsche Erklärung. Der Origin verantwortet die Klassifikation; der Cache verantwortet die tatsächliche Trennung beim Hit.

Der übersprungene Origin muss nachweisbar bleiben

Ein Evidenzsatz verbindet sichtbare Request-URL, gespeicherte URL und Rohfeld, geparste Konfiguration, transformierte Vergleichspaare, ausgewählten Eintrag, alle übrigen RFC-9111-Prüfungen, User- und Partition-Kontext, Origin Bypass und Body-Fingerprint. Eine Hit Rate kann richtige Äquivalenz nicht von effizientem Leakage unterscheiden.

Lu Hengs minimale gemeinsame Spezifikation erklärt die Aufteilung: Gemeinsam sind Dictionary und Vergleich; die lokale Anwendung entscheidet über ihre Schlüssel; jeder Cache adoptiert freiwillig. Die Primarität laufenden Codes verlangt den Nachweis der tatsächlichen Auswahl und Lieferung, nicht nur eines gesetzten Felds.

Auch technische und praktische Datensouveränität fallen auseinander. Der Origin kontrolliert formal die Erklärung, Browser und CDN halten URL und Logs, der Cache hält den Body; der Origin sieht den bedienten zweiten Request womöglich nie. Governance muss dieser realen Verwahrung folgen.

Unsicherheit darf einen zusätzlichen Miss erzeugen. Sie darf keine Nutzerschranke entfernen.