👍 I've been getting around this with something like rsp.headers.append(SURROGATE_CONTROL_HEADER, `max-age=${cacheTTL}`); in the custom fetcher.

Where cacheTTL is the calculated TTL based off Cache-Control and some other headers.

100% agreed re making the surrogate control header configurable.

I'm not sure about making Cache-Control configurable. I think the behaviour would need to be heavily documented and I'm not clear on what the behaviour should be.

Are you saying that if a custom Cache-Control header is set then we should just treat it as the normal header and the behaviour remains the same? What if they have a custom header set but then also send Cache-Control. Do we ignore it?

👍 I've been getting around this with something like rsp.headers.append(SURROGATE_CONTROL_HEADER, max-age=${cacheTTL}); in the custom fetcher.

Interesting. I suppose I could do something similar, but I think I'd still have to resort to cdn-cache-control for other directives (like stale-while-revalidate).

Interesting I didn't realise that cdn-cache-control supported stale directives.

If I made cache-control configurable would you expect the library to just treat the configured header exactly the same as Cache-Control ?

I'm not sure that would work as peoples browsers would still likely cache things which causes issues.

Since CDN-Cache-Control is only used by CDNs anyway that would likely be consumed by the CDN PRIOR to the worker even modifying anything anyway.

So the only thing that matters is down stream (ie peoples browsers).

Yeah, cdn-cache-control has the same directives as cache-control. And Cloudflare (kind of*) supports stale-while-revalidate: https://developers.cloudflare.com/cache/concepts/revalidation/#example-1

So the only thing that matters is down stream (ie peoples browsers).

That sounds right – if the reason to set private, max-age=0 here is so it gets back to the browser, then it shouldn't be configurable.

• Cloudflare's implementation re-validates synchronously for the first request, so there will still be one user that gets an un-cached response. If you want a fully async revalidation, you have to implement it yourself in your worker.

Interestingly, it seems this behavior comes from the Surrogate-Control spec, not just from Cloudflare: https://www.w3.org/TR/edge-arch/

Surrogates should ignore any HTTP Cache-Control request header directives.

…which I suppose is probably why CDNs need CDN-Cache-Control to be a thing.

@timkelty I'll get the Surrogate-Control header changes released later on this week when I merge it in.

I'm not convinced there is a need to move the Cache-Control header off to a different header as by the time it hits the worker it's POST CDN Consumption and the only thing down stream is the end users browser. That browser is only going to be interested in Cache-Control regardless.

If you still think there is a valid use case for it please let me know.

Thanks so much!

Yep – agreed about Cache-Control.