Re: New Version Notification for draft-cdn-control-header-00.txt

Hi Piotr,

> On 27 Jan 2021, at 6:03 am, Piotr Sikora <piotrsikora@google.com> wrote:
> 
> Hi Ben,
> 
>> I think CDNs are a special case. CDNs are typically considered to be “delegated origins” (i.e. from an authority/caching perspective they are an extension of the origin rather than a “consumer” side cache).
>> 
>> This leads to lots of use cases where one would like the caching behaviour of the CDN (acting as an extension to the origin) to be different to the caching behaviour of any downstream (from the origin/CDN) caches.
> 
> The same is true for reverse proxies, local gateways and caching cloud
> load-balancers. Again, the intent to make the content cacheable at the
> "delegated origins" is the same, regardless of the specific
> deployment.

Absolutely. The question is whether sites need to be able to distinguish *between* those different types of deployments. There's lots of evidence that at least for CDNs, they do; pretty much every CDN has its own "control me" header, and the variety is a headache for customers who want to switch between CDNs easily, or go multi-CDN.


>> The current Cache-Control header semantics are not rich enough to express the uses cases that already exist and so they are typically implemented via CDN-specific/proprietary configuration/policies. This header would remove that need and provide a single mechanism to express the required CDN caching “policy” regardless of CDN which would improve interoperability vs today’s mess of CDN-specific configuration.
> 
> CDN-Cache-Control (as written today) is limited to "max-age",
> "must-revalidate", "no-store", "no-cache", and "private", so it
> primarily fixes incompatibilities between "s-maxage" and "no-store" /
> "no-cache". I don't believe it allows for expressing richer policy
> than Cache-Control.

CDN-Cache-Control, just like Cache-Control, is extensible -- see <https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#cache.control.extensions>.


> But this is what I'm talking about - if local gateways or even reverse
> proxies are expected to honour the CDN-Cache-Control header, then it's
> not really a CDN-specific header, and we should have something more
> generic than that.

They're not - they're expected to ignore it, unless they're specifically configured to pay attention (because they're part of what the deployment considers to be a CDN).


> Also, I'm not a HAProxy user, so I cannot speak to that specific
> implementation, but I know it's impossible to configure other proxies
> to consume cache control instructions from a "random" header, so we
> would need all open source proxies to explicitly support
> CDN-Cache-Control header.

Only if they wanted to be able to be controlled in this fashion.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 28 January 2021 08:44:45 UTC