We just shipped support for the ugliest part of HTTP: Vary

We just shipped support for the ugliest part of HTTP: Vary blog.cloudflare.com

Vary support is now available in Cache Rules on every plan. You can normalize known negotiation headers, pass exact values through to the origin when those small differences matter, or bypass cache when the variation…

150 points•thisisfatih•7 days ago•40 comments•

#vary #http #just #ugliest #shipped #ugliest part #just shipped #shipped support

40 comments

simonw7 days ago

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.)

Joker_vD7 days ago

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).

yoavm7 days ago

I always thought Accept (and Accept-Language) headers are quite neat. Surely I can try article.es.md first, get a 404, try article.en.md, get a 404, try article.es.txt, article.en.html and so on, until I find the thing I'm looking for. But Accept let's me say "I'll take any one of these, preferably in this order". This is especially useful now when agents are reading the web and they don't really need all of our HTML code - just the text.

If you're versioning the whole API though, I agree it's best behind a a /v2/ prefix.

cryptonector6 days ago

REST is all about MIME types and Accept/Content-Type. So there goes REST.

TFA makes me think that your argument is stronger than I would have thought yesterday, though I still prefer to have Accept/Content-Type negotiation. Sibling's comment about negotiation is on-point.

ramblerman5 days ago

It sounds like you came up with a proper solution because cf didn’t support this silliness

colmmacc7 days ago

Wow this brings back memories. Over twenty years ago I added Vary support to various mod_cache submodules for Apache 2.0, and it was way too high a pain to reward ratio. It just uncovered so many user agent bugs and crazy backends. I remember arguments about being able to cache variable based on non-literal virtual headers (e.g. a geo location header), and a crazy request to Vary based on "Date:" ... which makes absolutely no sense. The whole thing was just too clever for its own good. It's no surprise that language selection ended up in URLs (/en-US/..) rather than "Vary: Accept-Lang" features.

Gigachad7 days ago

I feel like putting as much as possible in the URL is a good thing anyway. If I send someone a link, I can know it's the same document that shows on their browser as mine.

KyleTheDev6 days ago

Yea, from a UX perspective, being able to send your friend a URL and know that they're seeing exactly what you see is awesome. It makes support/debugging/etc nicer too, if you're trying to walk somebody through something.

tiffanyh7 days ago

I just wish CF would enable Enterprise functionality to lower (paid) tiers as they promised a year ago yet haven’t delivered on.

https://blog.cloudflare.com/enterprise-grade-features-for-al...

Like Prefetch: https://developers.cloudflare.com/speed/optimization/content...

jiehong7 days ago

Is Vary really that ugly?

I’d say that it forces you to maybe parse and understand the headers that vary header.

Accept-Language is supposed to be parsed and matched according to RFC4647 in one of 3 ways. That part is rather complex, but it’s not Vary’s fault.

kevincox7 days ago

One major issue with Vary is that it makes cache coalescing very complicated. This is because you can't know whether two requests will share a response until you get that response. So for subsequent requests you need to decide if you should block it hoping that the response will satisfy it or if you should send it through pessimistically, possibly triggering a thundering herd effect on every cache rotation.

I'm not sure if it is possible to solve this nicely in a generic way, but it does make it a bit ugly.

cryptonector6 days ago

This is not caused by Vary but by the app being so.. variable.

If you segregate content-type/language by end-point then the variability goes away. But now you have a plethora of end-points. The complexity can get moved around, and in this particular case the complexity for the caching layer can be removed, but the complexity isn't gone.

jrochkind17 days ago

I had not actually realized what a mess Vary is.

Wow, sometimes I think it's amazing the web works at all!

saltcured7 days ago

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.

rmunn7 days ago

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.

sandeepkd7 days ago

Wait a second, if you decided to become intermediary in the protocol then you are supposed to add value, not take away the features that already exists.

Although its not clear from the article itself, my gut feeling is that some big enough client arm twisted them to support it before they sign the contract again

mikestorrent7 days ago

Imagine if we actually built a remote application delivery platform instead of cobbling one onto a glorified document reader

Read the full thread on Hacker News →

40 comments

Related stories