Cloudflare adds Vary header controls to Cache Rules on every plan

Cloudflare ships Vary support

Cloudflare has shipped support for the Vary response header in Cache Rules, and according to the Cloudflare blog it is available on every plan. Vary is the standard HTTP mechanism an origin uses to tell intermediary caches which request fields can change a response, and it has a long-standing reputation for being painful: Cloudflare opens by citing an existing description of it as one of the ugliest, still-unimproved corners of HTTP, with poor interoperability between intermediaries.

Why Vary exists

A single URL can legitimately have more than one correct response. Servers deliver different languages, image formats, compression schemes or regional content depending on what a client asks for, and Vary names the request fields that influenced the choice.

Without it, the first response a cache stores for a URL gets served to everyone. The blog's example is an endpoint that returns HTML to a browser and JSON to an API client for the same path. If the cache ignores Vary, whichever representation arrives first wins, and the other client receives bytes it cannot parse.

Correct caching that becomes useless

Honoring Vary naively creates the opposite problem. The header says which request fields may affect a response, but not which differences actually matter. Two Accept-Language values such as "en-US, fr;q=0.8" and "fr;q=0.8, en-GB" both prefer English, and an origin that only serves English, French and German may return identical bytes for both — yet a cache comparing raw values cannot safely treat them as equivalent, and may store separate variants anyway.

Fragmentation compounds quickly, as the blog explains: ten possible values in one field make ten variants, while ten values across three fields can make 1,000 combinations. Real headers are worse — User-Agent values are numerous, cookies are often unique per visitor, and preference headers differ in ordering, spacing and quality values. The result can be a cache that is technically correct yet full of entries nobody reuses: identical responses scattered across cold variants that consume capacity, evict one another, drag down hit ratios and push more requests back to the origin.

The problem is widespread in practice. Cloudflare analyzed more than 120 million responses from nearly 50,000 popular sites and found almost 3,000 sites varying on four or more fields, with some varying on 10, 23 or even 47 fields.

Three actions per header

The feature splits the decision in two. The origin still uses Vary to declare which request headers may affect a response; the Cache Rule decides how Cloudflare treats each named header's value. Three actions are available:

• normalize, the recommended default. Cloudflare normalizes request headers before selecting a cached variant so equivalent requests share an entry. Header-specific rules apply to Accept, Accept-Language and Accept-Encoding; other headers get optional whitespace trimmed and repeated header lines combined in their original order, with casing and interior whitespace preserved.
• passthrough. The header's raw bytes are used for cache matching, preserving casing, whitespace, order and duplicate values, with multiple header lines combined in order using commas. This suits headers with a controlled set of values where the exact value changes the response. Cloudflare can still rewrite Accept-Encoding in this mode when Respect Strong ETags is disabled.
• bypass. Cloudflare does not store the response when the origin names that header in Vary. This is aimed at personalized, high-cardinality or unexpected headers such as Cookie or User-Agent. Existing entries are not removed, so a purge is needed to clear them.

A rule does not force every response to vary. If the origin returns no Vary header, Cloudflare caches the response normally, though the rule may still rewrite Accept and Accept-Language before forwarding the request upstream. Headers without an individual setting fall back to the rule's default action.

Cloudflare notes that customers already had workarounds — bypassing cache, reproducing origin negotiation logic in a custom cache key, writing a Worker, or using narrower features like Vary for images — but each either gave up caching, duplicated application logic, required extra code, or covered a limited use case.

Why it matters

Vary sits squarely between two failure modes: ignore it and you serve the wrong content to the wrong client; honor it literally and your cache fragments into entries that are never reused. HTTP itself never resolved this, because the header carries no semantics about which request differences are meaningful to the application. Cloudflare's answer is to hand that judgment to the operator, per header, with a sensible default in normalize. For sites that negotiate content heavily — images, languages, encodings — this can translate directly into better hit ratios and less origin load. And because it ships on every plan rather than as an enterprise extra, it is likely to raise the baseline quality of caching across a large slice of the web.