Cloudflare finally tackled the Vary header disaster

The Vary response header is essentially the "junk drawer" of HTTP—a kludgy, abysmal mechanism that usually makes engineers want to quit their jobs. But because it's the only way to tell a cache that one URL might have multiple correct responses (like serving WebP to one browser and JPEG to another), we're stuck with it. Cloudflare just rolled this out into Cache Rules for all plans, meaning you can finally stop the cache from either serving the wrong bytes or exploding into thousands of useless entries.

Why Vary is a technical nightmare

The basic logic is that a server uses Vary to say, "Hey, the response depends on this specific request header." For example, if a URL serves both HTML and JSON, the origin sends Vary: Accept. If a browser asks for HTML and an API client asks for JSON, the cache needs to know that the URL alone isn't enough to identify the content. Without this, the first response to hit the cache wins, and suddenly your API client is trying to parse a full HTML page, which is a great way to crash an app.

The real mess starts when the cache actually listens to Vary. The header tells the cache which field matters, but not which values within that field actually result in different content.

The cardinality explosion problem

Here is where it gets ridiculous. Imagine a server that only supports English, French, and German. A user might send a request with:
Accept-Language: en-US,en;q=0.9

Another user sends:
Accept-Language: en-GB,en;q=0.8

Both want English. The server sends the exact same English page to both. However, a standard cache sees two different raw strings and stores two separate copies of the same page. When you multiply this across three different headers with ten variations each, you suddenly have 1,000 cache entries for content that is identical. Between User-Agent strings and cookies, the cardinality becomes a nightmare where the cache is "correct" but completely useless because the hit rate drops to zero.

How to actually manage it now

Since this is now in Cache Rules, you don't have to just accept the chaos. You can actually decide how the variation is handled:

1. Normalize headers: You can collapse those thousand different "I prefer English" variations into one single bucket so the cache actually works.
2. Exact matches: If a tiny difference in a header actually does change the content, you can tell the cache to treat them as distinct.
3. Bypass entirely: If the variation is too unpredictable to manage, just skip the cache for those requests.

Essentially, the origin declares what might vary, but you now get to decide how much of that variation is actually meaningful. It's a rare case of taking a "horrible" HTTP standard and making it actually usable.