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

Hi Piotr,

> On 26 Jan 2021, at 09:00, Piotr Sikora <piotrsikora@google.com> wrote:
> 
>> CDNs are different in that they're a non-local gateway ("reverse proxy") cache; having a single header that targets them (as opposed to local gateways and "forward' proxies, along with server-side and UA caches) promotes interoperability. The point here is to allow an origin server to set one header and know that it'll still operate when they switch CDNs. More to the point, it's so that content frameworks like Drupal and Wordpress can set CDN-specific caching information "out of the box".
>> 
>> Local gateway caches might also benefit from something like this, but it needs to be separate from the non-local gateway instructions; that seems to be now fully emerged common architecture. "CDN" was chosen because a) it's short and b) because it aligns with how everyone thinks about "non-local gateway cache."
>> 
>> So if there's demand for it,* I could see:
>> 
>> 1) Cache-Control --> all caches unless overridden
>> 2) CDN-Cache-Control --> non-local gateway caches
>> 3) ???-Cache-Control --> local gateway caches
>> 4) xxx-Cache-Control --> implementation/deployment specific override
>> 
>> For #3, maybe Gateway-Cache-Control?
>> 
>> * I think the question here is whether interoperability would be improved by having a single control mechanism for these local gateway caches -- i.e., would someone swap out Squid for Nginx or Varnish for ATS and expect it to still work?
> 
> I strongly disagree with the premise that this draft does anything to
> improve interoperability, it does the opposite.
> 
> Nowadays, virtually all downstream caches support Cache-Control:
> s-maxage (I understand that it conflicts with no-store, etc. so we
> need an improved version, hence this proposal), so when an application
> developer deploys their service, it doesn't matter whether it's
> fronted by NGINX or Varnish or HAProxy, or maybe even FooCDN, they all
> respect the same header. The intent to make the content cacheable is
> there.
> 
> The current proposal replaces that intent with deployment details,
> something that the developers often have no control over. E.g. imagine
> an application developer using FooPaaS, where they deployed their Go
> application. If the FooPaaS provider makes any changes to the
> networking layer (e.g. switching from local NGINX caching gateway to a
> 3rd-party CDN or vice-versa), then content suddenly becomes
> uncacheable, even though the intent is still there. Similarly, in
> enterprise environments, where the networking layer and applications
> are owned by different teams, the cacheability shouldn't be affected
> by changes to the underlying infrastructure.
> 
> I'm fine with replacing Cache-Control: s-maxage with a generic
> Proxy-Cache-Control (or whatever we want to call it), but I don't see
> how adding dedicated CDN-Cache-Control (or worse,
> VENDOR-CDN-Cache-Control) benefits users.

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

My guess is that proxies such as nginx/haproxy/etc would add support for CDN-Cache-Control (as they are often deployed within CDNs or as part of a provider’s origin infrastructure) and would provide a configuration switch to honour it or not (probably not honouring it by default). [Note: I am not involved with any proxy implementations so I cannot speak on their behalf regarding their actual plans for implementation]

In your FooPaaS provider case, if FooPaaS provider is using a CDN (which they consider to be an extension of their origin) and they are sending CDN-Cache-Control and they decide to change to using, say, haproxy instead (and they still consider haproxy to be an extension of their origin) then they would configure haproxy to honour the CDN-Cache-Control header so the caching behaviour would be the same as before.

Regards
Ben

Received on Tuesday, 26 January 2021 10:59:43 UTC