Cloudflare hat den HTTP-Vary-Header aufgeteilt in das, was variiert, und das, wie stark es zählt

Der HTTP-Vary-Header teilt Caches mit, welche Anfrage-Header eine Antwort beeinflussen können, damit ein Cache nicht das HTML eines Browsers an einen API-Client ausliefert, der JSON anfordert. Cloudflare verweist auf eine externe Analyse von über 120 Millionen Antworten auf fast 50.000 populären Websites, die fast 3.000 fand, die auf vier oder mehr Feldern variieren, einige auf 10, 23 oder sogar 47. Vary ist korrekt, aber wörtlich genommen kann es Caching nahezu wertlos machen: Zehn Werte über drei Felder erzeugen bereits bis zu 1.000 Varianten, und Header wie Accept-Language können sich in Reihenfolge oder Formatierung unterscheiden, während sie für den Origin dasselbe bedeuten.

Das Ergebnis ist ein Cache, der „vollkommen korrekt und fast dauerhaft kalt“ ist: byte-identische Antworten verteilen sich auf viele kaum wiederverwendete Einträge, verdrängen sich gegenseitig und schicken mehr Anfragen zurück zum Origin. Bestehende Workarounds – den Cache vollständig umgehen, die Aushandlungslogik in einem Worker duplizieren oder enge Funktionen wie Vary for images – gaben jeweils das Caching auf, duplizierten Anwendungslogik oder deckten nur einen Fall ab.

Cache Rules erlauben es dem Origin nun, weiterhin Vary-Header zu deklarieren, während eine Regel-Einstellung pro Header entscheidet, ob Werte in eine kleine Äquivalenzmenge normalisiert, exakte Werte durchgereicht oder für unvorhersehbare Header das Caching umgangen wird. Zwei Accept-Language-Anfragen, en-US, fr;q=0.8 und fr;q=0.8, en-GB, die beide Englisch bevorzugen, können unter normalize nun einen gemeinsamen Cache-Eintrag teilen, statt zu zwei Varianten zu werden, während ein Header, der exakt variieren muss, passthrough verwenden kann. Es ist ab heute in den Tarifen Free bis Enterprise verfügbar.

Trenne, was variiert, davon, wie viel Variation zählt

Das Normalisieren von Accept und Accept-Language durch Sortieren nach Qualitätswert und Reduzieren auf eine konfigurierte Menge von Formaten fasst Anfragen, die byte-verschieden, aber semantisch identisch sind, zu einem Eintrag zusammen.

Die Wahl zwischen normalize/passthrough/bypass pro Header statt global erlaubt es einem Betreiber, Cookie als unbegrenzt (bypass) zu behandeln, während Accept-Language als kleine geschlossene Menge (normalize) behandelt wird.

Das Weiterleiten des normalisierten Header-Werts an den Origin, nicht nur seine Verwendung für den Cache-Schlüssel, hält die Antwortauswahl des Origins damit im Einklang, als welche Cache-Variante sie gespeichert wird.

Vary: * umgeht weiterhin immer den Cache, da es Faktoren außerhalb der HTTP-Nachricht signalisieren kann, etwa die Client-IP, die die Antwort bestimmt haben, was keine Regel auf Header-Ebene sicher normalisieren kann.

Wenn ein Korrektheitsmechanismus in kombinatorische Verschwendung explodiert, finde heraus, wo du „verschiedene Bytes“ und „verschiedene Bedeutung“ als dasselbe behandelst, und gib dem Betreiber für jedes einen separaten Regler.

Cloudflare gibt an, zu prüfen, ob Ideen aus dem abgelaufenen IETF-Draft „Availability Hints“ es Origins ermöglichen könnten, ihre unterstützten Repräsentationen direkt zu beschreiben, wodurch der manuelle Aufwand verringert würde, zu konfigurieren, welche Formate und Sprachen eine Cache Rule normalisieren soll. Der Beitrag rahmt die aktuelle Aufteilung normalize/passthrough/bypass als Schließen einer Lücke zwischen bestehenden Optionen (vollständiges Bypassen, benutzerdefinierte Cache-Schlüssel oder Worker-basierte Aushandlungslogik) und nicht als endgültiges Design.