The classic problem here is if you do that thing where user agents that send "accept: text/html" get HTML, while user agents that don't get JSON or some other format.
This used to be impossible to deploy behind Cloudflare caching, because they ignored the Vary header on anything other than images - so you risked caching the JSON version and then serving it up to someone who was expecting HTML.
(Independent of the Cloudflare feature I ended up deciding never to use that pattern, because I prefer having URL that predictably returns HTML or JSON - I add a .json suffix to my apps to serve JSON instead.)
Frankly, the supposed variability of the Accept header never really sat all that well with me; in practice I much prefer working with explicitly versioned endpoints — one of the most infuriating things is having to hardcode "Accept: text/x-myorgname-custom-json-blob-v4" because omitting it would produce "406 Not Acceptable". Bonus points if that's the only Accept header the service would ever accept in all of three years of it working before being decommissioned. Double bonus points if v5 would be introduced behind a separate URI anyway (and it, too, would require precisely "Accept: text/x-myorgname-custom-json-blob-v5" and nothing else).
It pains me to think about the important ones like varying on session cookie and authorization headers, and how badly some middleware can confuse things.
We generate custom content for a given authentication context. We definitely want caching at the user agent, but we want the cache keyed by the authenticated identity. Otherwise something like logging out and logging in as a different identity can produce monstrously confused results when an SPA or similar mixes some cached and some fresh responses into one page.
They can't do that because a CMS under Cloudflare needs to be configured to bust the Cloudflare cache when content is edited or the user will see cached content after they edit a page.
That might be the default configuration if your CMS doesn't return any cache-control headers. But Cloudflare definitely [0] supports must-revalidate and etag or last-modified, which is also probably supported by whatever CMS you're using. HTTP conditional requests are very old and very widely supported.
[0] Okay, my claim is only definite up to my memory of using Cloudflare for a fairly high-traffic circa 2019-2022. I haven't used Cloudflare after that point, but a quick search of their docs shows support
I've been wanting this from Cloudflare for years.
The classic problem here is if you do that thing where user agents that send "accept: text/html" get HTML, while user agents that don't get JSON or some other format.
This used to be impossible to deploy behind Cloudflare caching, because they ignored the Vary header on anything other than images - so you risked caching the JSON version and then serving it up to someone who was expecting HTML.
(Independent of the Cloudflare feature I ended up deciding never to use that pattern, because I prefer having URL that predictably returns HTML or JSON - I add a .json suffix to my apps to serve JSON instead.)
Frankly, the supposed variability of the Accept header never really sat all that well with me; in practice I much prefer working with explicitly versioned endpoints — one of the most infuriating things is having to hardcode "Accept: text/x-myorgname-custom-json-blob-v4" because omitting it would produce "406 Not Acceptable". Bonus points if that's the only Accept header the service would ever accept in all of three years of it working before being decommissioned. Double bonus points if v5 would be introduced behind a separate URI anyway (and it, too, would require precisely "Accept: text/x-myorgname-custom-json-blob-v5" and nothing else).
Nice to see. I’ve used vary to quite a bit of success on CloudFront back in the day.
I actually assumed when I started using Cloudflare that it did have vary support and it led to a serious bug in my sass app at the time.
I honestly thought they would never ship this. Holy hell this has been a long time coming.
Actual real content negotiation in 2026. Never thought I'd live to see the day.
"If the origin response does not include a Vary header, Cloudflare caches the response normally"[1]
"If one response omits it, Cloudflare could cache that response without the variance needed to keep it isolated."[2]
Will that non-Vary cache object front-run any Vary-segmented cache objects?
If so, probably worth adding a snippet rule to ensure every response has a Vary header?
1: https://developers.cloudflare.com/cache/concepts/vary/#how-v...
2: https://blog.cloudflare.com/vary-support/#how-a-response-mov...
finally. now maybe they'll have time to implement a working unsubscribe on their marketing emails.
Turns out their marketing can get to you through HN posts…
I had not actually realized what a mess Vary is.
Wow, sometimes I think it's amazing the web works at all!
It pains me to think about the important ones like varying on session cookie and authorization headers, and how badly some middleware can confuse things.
We generate custom content for a given authentication context. We definitely want caching at the user agent, but we want the cache keyed by the authenticated identity. Otherwise something like logging out and logging in as a different identity can produce monstrously confused results when an SPA or similar mixes some cached and some fresh responses into one page.
Cache invalidation, one of the two hard problems in computer science.
I'm sure most people here already knows the joke, but for the lucky 10,000, here's the full joke:
There are only two hard problems in computer science. Naming things, cache invalidation, and off-by-one errors.
And, for those who don't know who the lucky 10,000 are, https://xkcd.com/1053/
Imagine if we actually built a remote application delivery platform instead of cobbling one onto a glorified document reader
If this surprises you, remember that Cloudflare doesn't cache HTML by default.
They can't do that because a CMS under Cloudflare needs to be configured to bust the Cloudflare cache when content is edited or the user will see cached content after they edit a page.
OTOH a CMS that doesn’t send correct cache headers is already broken
That might be the default configuration if your CMS doesn't return any cache-control headers. But Cloudflare definitely [0] supports must-revalidate and etag or last-modified, which is also probably supported by whatever CMS you're using. HTTP conditional requests are very old and very widely supported.
[0] Okay, my claim is only definite up to my memory of using Cloudflare for a fairly high-traffic circa 2019-2022. I haven't used Cloudflare after that point, but a quick search of their docs shows support
A site I work on serves dynamic language content based on the accept-language header. We do this for some pages and others we redirect to i.e /en/page
But we can't cache those dynamic pages since they vary based on accept language. Maybe with this we can