Comment by Rauchg | Hacker News Reader

Comment by Rauchg | Hacker News Reader

The gist is (which the support engineer referred to as the internal RFC): instead of stripping `cache-control` `s-maxage` / `stale-while-revalidate` values, we should support Targeted HTTP Cache Control[1] (i.e.: `cdn-cache-control` and `vercel-cache-control`).

Vercel strips them because (1) at the time this RFC didn't exist and (2) most of the time you we found customers don't want to cache on the browser side or proxying CDNs, which makes purging and reasoning about cache staleness very difficult.

Another example there is the default `cache-control: public, max-age=0, must-revalidate`. Without that, browsers have very unintuitive caching behavior for dynamic pages.

Customers want to deploy and see their changes instantly. They want to their customers "go to our blog to see the news" and not have to second guess or fear the latest content will be there.

I appreciate Max's feedback and we'll continue to improve the platform.

[1] https://httpwg.org/specs/rfc9213.html

Cloudflare (and likely other cdns) has a development mode for this exact use case

Unless I'm misunderstanding you: it's not about dev or prod. It's that you want Vercel to cache a dynamic page, but not your visitor. That allows you to be in control of the ship: if you purge the CDN, you don't risk a customer having a stale page.

I've seen a lot of customers get burn by sending `max-age` as a way of getting their CDN to cache, not realizing they're inadvertently caching on users' machines. Sometimes it's a seemingly harmless "5 minutes", but that can be damaging enough for rapidly changing pages (imagine breaking news on a homepage).

Look, regarding setting cache-control headers, it's a professional tool, and it's going to be possible to shoot yourself in the foot with it. The approach to try to reduce that is to have a UI that asks people, "hey are you sure you want to do this potentially dangerous thing? It just result in these unintended consequences", but yes, ultimately allow people to do it. Otherwise, you're not letting people use what they paid for.

Totally, I don't like surprising behaviors either. At the time we made that decision the `CDN-Cache-Control` proposal didn't exist, so it was a tricky spot.

There also really wasn't a UI opportunity in this case (although one thing we thought about was a setting to control it and turn off the Vercel override).

> There also really wasn't a UI opportunity in this case

Why, because the configuration is set in a text file and not in the UI?

You could send an automatic email to the account holder with the warning whenever someone adds a foot-gun cache-control setting, with the ability to turn off the email by setting a different configuration flag to true or by checking a flag in the UI.

Reply on news.ycombinator.com