Cloudflare hat Vary endlich gewöhnlichen Nutzern zugänglich gemacht, und das Unternehmen ist bestrebt, die Nachricht zu verbreiten. Die Funktion platziert die Kontrolle über HTTPs verwirrendsten Header direkt in den Händen der Kunden. Anstatt zu erlauben, dass Vary Ihren Cache beeinträchtigt, können Sie nun Cloudflare anweisen, welche Variationen wirklich wichtig sind.
Die Ankündigung kommt mit einer Warnung. Vary sei „der hässlichste Teil von HTTP, den wir bisher noch nicht verbessert haben“, wie ein Beitrag es ausdrückte, und es habe „ziemlich erbärmliche Interoperabilität“ über Zwischenhändler hinweg. Das ist normalerweise der Punkt, an dem vernünftige Ingenieure langsam mit hochgehobenen Händen zurückweichen. Aber Cloudflare weicht nicht zurück. Das Unternehmen hat ein System aufgebaut, das es Kunden ermöglicht, zu entscheiden, wie viel Variation für den Cache sinnvoll ist, anstatt mit dem zu hängen bleiben, was die Quelle erklärt.
Was Vary tatsächlich tut
Der Vary-Header ist ein HTTP-Antwort-Header, der zwischengeschaltete Caches, wie Cloudflare, anweist, welche Anfragefelder die Antwort beeinflussen können, die vom ursprünglichen Server ausgestellt wird. Ein Server könnte verschiedene Bildformate an verschiedene Browser ausliefern oder unterschiedliche Sprachen von derselben URL bereitstellen. Wenn ein Cache Vary übersieht, besteht das Risiko, die falschen Bytes für eine Anfrage bereitzustellen. Wenn er jedoch jeden Rohheader-Wert als getrennt betrachtet, können eine kleine Anzahl verwandter Anfragen zu Tausenden von kaum wiederverwendbaren Cache-Einträgen anwachsen.
Ein Header ist einfach zu erklären, aber schwierig zu handhaben. Die Quelle identifiziert die Anfrage-Header, die die Antwort beeinflussen könnten, während Sie wählen, wie Cloudflare mit jedem einzelnen umgeht. Sie können bekannte Verhandlungs-Header standardisieren, exakte Werte senden, wenn diese geringfügigen Unterschiede wichtig sind, oder den Cache vermeiden, wenn die Variation zu unvorhersehbar wird.
Das zentrale Problem
Das Problem beginnt mit den Grenzen des Headers. Er weist darauf hin, welche Anfragefelder eine Antwort beeinflussen könnten, versagt aber, zu sagen, welche tatsächlichen Änderungen wirklich zählen. Diese Lücke ist genau das, was die Dinge erschwert.
Nehmen wir an, eine einzelne URL kann zwei unterschiedliche, gültige Versionen einer Webseite erzeugen. Wenn ein Browser danach fragt,
GET /catalog HTTP/1.1
Host: example.com
Accept: text/html
wird HTML vom ursprünglichen Server zurückgegeben, und Accept wird als Feld identifiziert, dessen Vorhandensein die Antwort beeinflussen kann.
Die Antwort beginnt mit einer HTTP-Statuszeile, die eine erfolgreiche Anfrage ankündigt: HTTP/1.1 200 OK. Darunter folgt ein Content-Header, der den Dokumenttyp spezifiziert, gefolgt von einer Cache-Direktive, die ein öffentliches Maximum-Alter von 3600 Sekunden festlegt. Der abschließende Header, Vary: Accept, signalisiert, dass die Antwort des Servers von dem abhängen kann, was der Client akzeptiert.
Wenn ein API-Client eine Anfrage an dieselbe URL sendet, kann er eine andere Präferenz angeben.
GET /catalog HTTP/1.1
Host: example.com
Accept: application/json
Dieses Mal ist die korrekte Antwort JSON. Der Vary: Accept-Header deutet an, dass der Cache nicht ausschließlich auf die URL angewiesen sein sollte, um eine Antwort auszuwählen; er muss auch den Accept-Wert der Anfrage berücksichtigen.
Ohne Vary kann die erste Antwort, die in den Cache eintritt, an beide Clients ausgeliefert werden, unabhängig davon, welcher es ist. Wenn HTML vor JSON ankommt, erhält der API-Client Markup und sein JSON-Parser schlägt fehl. Wenn JSON zuerst ankommt, erhält ein Browser, der eine Webseite erwartet, eine API-Antwort. Vary verhindert, dass der Cache den falschen Antworttyp an den anfragenden Client ausliefert. Dennoch wirft es eine schwierigere Frage auf: Müssen zwei Anfragen mit unterschiedlichen Header-Werten wirklich getrennte Antworten haben?
Wann korrektes Caching nutzlos wird
Eine Situation wird komplizierter, wenn sich eine Antwort über mehrere Felder gleichzeitig ändert. Betrachten wir einen Ursprung, der Inhalte nur in drei Sprachen anbietet – Englisch, Französisch und Deutsch – und stellen wir uns vor, was passiert, wenn ein Client eine Anfrage sendet, die nach Informationen zu mehr als einem dieser Felder gleichzeitig fragt.
Accept-Language: en-US, fr;q=0.8
Während ein anderer Client Folgendes anfordern könnte:
Accept-Language: fr;q=0.8, en-GB
Die beiden Anfragen bitten um dieselbe Sprache, doch der Server behandelt sie als unterschiedlich und speichert jede davon als ihre eigene Version trotz übereinstimmendem Inhalt. Dies geschieht, weil jede Anfrage ihre eigenen Reihenfolge- und Sprach-Tags enthält, und der Server kann diese nicht von selbst unterscheiden. So können zwei identische Antworten als separate Varianten im Cache gespeichert werden.
Das Kernproblem mit Vary besteht darin, dass Apps häufig eine begrenzte Anzahl von Ausgabeformaten aus einer großen Anzahl potenzieller Eingabeanfragen erstellen. Das Quellsystem erkennt, dass viele Benutzerpräferenzen für Sprachen auf nur drei unterstützte Optionen hinauslaufen, während ein Cache im Allgemeinen nicht über diesen Kontext verfügt.
Ein Cache kann zwar vollkommen korrekt sein, ist aber dennoch fast dauerhaft kalt. Ähnliche Antworten können über Einträge verteilt sein, die zu wenig Traffic verzeichnen, um warm zu bleiben und im Cache zu verbleiben. Diese können Platz einnehmen, sich gegenseitig verdrängen, die Trefferquoten senken und mehr Anfragen an Ursprungsserver erzwingen. Während die Eviction kalte Einträge entfernt, bietet sie keine Möglichkeit, diese zu kombinieren, einfach weil ihre Antworten übereinstimmen.
Eine Studie, die auf über 120 Millionen Antworten von fast 50.000 bekannten Websites basiert, entdeckte fast 3.000 davon, die sich über vier oder mehr Kategorien hinweg unterscheiden. Andere änderten sich nur in 10, 23 oder sogar 47 Kategorien. Das Unternehmen zielt darauf ab, sicherzustellen, dass Benutzer die Möglichkeit haben, Vary angemessen anzuwenden, ohne dabei einen übermäßigen Speicherbedarf zu erzeugen.
High-Cardinality Variation Is Deliberate
Bestimmte Änderungen sind absichtlich. Content Delivery Networks und Reverse Proxies können Werte hinzufügen, darunter eine geografische Region, um Inhalte systematisch zu organisieren. Dieser Ansatz gelingt, wenn die potenziellen Werte begrenzt sind und alle Komponenten das gleiche Verständnis davon haben, was sie bedeuten. Andernfalls zerfällt der Cache in Varianten, die möglicherweise nie wieder verwendet werden.
How Cache Rules Control Vary
Vor heute hatten Cloudflare-Kunden mehrere Möglichkeiten, um Inhalte zu behandeln, die eine ausgehandelte Behandlung erfordern, ähnlich wie Vary dies tut. Sie konnten wählen, den Cache vollständig zu überspringen und ihren Ursprungsserver die Aushandlung direkt verwalten zu lassen. Sie konnten auch einen benutzerdefinierten Cache-Schlüssel erstellen oder eine andere Regel anwenden, die die Aushandlungslogik des Ursprungs simuliert. Ein Worker war eine weitere Option, oder sie konnten Funktionen wie Vary für Bilder nutzen. All diese Methoden funktionieren weiterhin, bringen aber jeweils Kompromisse mit sich: einige verzichten ganz auf das Caching, andere erfordern die Duplizierung der Anwendungslogik, einige fordern das Schreiben von zusätzlichem Code, und andere decken nur eine eingeschränktere Anzahl von Fällen ab.
Diese überarbeitete Cache Rules-Methode behält genügend Variabilität, um die richtige Antwort zu liefern, während sie verhindert, dass geringfügige Unterschiede zwischen Anfragen die Cache-Leistung beeinträchtigen. Der Ursprung identifiziert weiterhin, welche Anfrage-Header eine Antwort beeinflussen können, aber Sie bestimmen, wie viel Variation für den Cache wirklich wichtig ist.
The Numbers Behind the Problem
- Mehr als 120 Millionen Antworten von nahezu 50.000 beliebten Seiten analysiert.
- Fast 3.000 Seiten variieren in vier oder mehr Feldern.
- Einige variierten in 10, 23 oder sogar 47 Feldern.
- Echte Header können eine viel größere Kardinalität haben: User-Agent-Werte sind zahlreich, Cookies können für einzelne Besucher eindeutig sein, und Präferenz-Header können sich in der Reihenfolge, Formatierung (Leerzeichen und Tabulatoren sind wichtig!) und Qualität unterscheiden.
Vergleich der Vorgehensweisen für den Umgang mit Vary
| Ansatz | Was es tut | Kompromiss |
|---|---|---|
| Cache umgehen | Die Origin-Seite bei der Aushandlung entscheiden lassen | Verzicht auf das Caching vollständig |
| Benutzerdefinierter Cache-Schlüssel | Reproduziere die Ursprungslogik in einer Regel (1) | Dupliziert Anwendungslogik (2) |
| Verwende einen Worker (3) | Behandle Variationen programmgesteuert (4) | Erfordert zusätzlichen Code (5) |
| Neue Cache-Regeln (6) | Entscheide, welche Variation zählt (7) | Bewahrt die Cache-Effizienz (8) |
Was Kunden jetzt tun können (9)
Jedes Plan unterstützt jetzt diese Funktion, die es Ihnen ermöglicht festzulegen, was an der Quelle geändert werden kann und dann Ihr eigenes Limit festzulegen, wie stark Unterschiede für die gespeicherte Kopie wichtig sind. Es geht über das hinaus, was zuvor möglich war. (10)
Das Unternehmen hat eine Methode entwickelt, die es Benutzern ermöglicht zu entscheiden, welche Versionen wichtig sind und welche einfach Hintergrund-Statistik sind. Cloudflare präsentiert nun diese Lösung seinem Publikum und bietet gleichzeitig eine Erklärung für das Problem selbst. (11)
Die Funktion ist live. Websites, die Vary verwenden, sollten sie testen, da die Alternative ein Cache wäre, der ordnungsgemäß funktioniert, aber nicht einmal einen einzelnen Artikel abgibt. (12)
Die Analyse stützt sich auf über 120 Millionen Antworten, die von fast 50.000 beliebten Seiten gesammelt wurden, von denen über 3.000 in vier oder mehr Feldern abweichen. Einige Seiten unterschieden sich nur in 10 Feldern, während andere in 23 oder sogar bis zu 47 Feldern abwichen. Die Daten sind in jedem Plan verfügbar.
Eine Lösung für das, was einst der hässlichste Teil von HTTP war, existiert nun, und ob Sie diese nutzen, hängt von Ihrer jeweiligen Website ab.
Quelle: „Wir haben gerade Unterstützung für den hässlichsten Teil von HTTP eingeführt: Vary“, cloudflare.com.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.