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

Hi Mark,

> That makes it harder to reuse existing Cache-Control machinery for the header; not a deal killer, but that's a major upside for adoption.

I was thinking about this for a while, but I don't see how this plays
any role in terms of adoption. All the web frameworks need to
explicitly add support for this new header, and CDN providers need to
generalize existing functions parsing the Cache-Control header anyway,
so I don't think it really matters.

> Also, I'd argue that it's harder for someone to understand when looking at the headers; in the current approach, there's a clear differentiation between the intended targets for the header.

If you're concerned about human-readability, then you can split the
list members across multiple headers:

    CDN-Cache-Control: for=vendor1; max-age=61
    CDN-Cache-Control: for=vendor2; max-age=62

it's all the same in the end.

Having said that, I'm not sure I completely understand the need for
vendor-specific headers. Are users expected to set different
expiration times for different vendors? What's the reasoning for this
feature?

> Remember, these are instructions, not just debug info; having a single header with sometimes conflicting instructions for multiple components is... tricky.

Exactly! Those are instructions for HTTP intermediaries, and I'm sure
that they can figure out how to split header values on the delimiters.

> I have serious doubts about whether that's going to get implemented correctly, and I don't think the impetuous is great enough to make a *replacement* cc header viable (see: Set-Cookie2).

Fair enough. Maybe let's drop the user-agent and keep using existing
Cache-Control for that purpose. How about Proxy-Cache-Control only for
intermediaries?

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

Best regards,
Piotr Sikora

On Mon, Jan 25, 2021 at 5:36 PM Mark Nottingham <mnot@mnot.net> wrote:
>
> Hi Piotr!
>
> > On 26 Jan 2021, at 10:49 am, Piotr Sikora <piotrsikora@google.com> wrote:
> >
> > Thanks for working on this! Two comments:
> >
> > 1) Since this header is already using structured headers, could we use a "for=" parameter instead of the suggested vendor-specific header names? i.e.
> >
> >   VENDOR1-CDN-Cache-Control: max-age=61
> >   VENDOR2-CDN-Cache-Control: max-age=62
> >
> > would become:
> >
> >   CDN-Cache-Control: for=vendor1; max-age=61, for=vendor2; max-age=62
> >
> > This would better match the style of Cache-Status and Proxy-Status headers, IMHO.
>
> That makes it harder to reuse existing Cache-Control machinery for the header; not a deal killer, but that's a major upside for adoption. Also, I'd argue that it's harder for someone to understand when looking at the headers; in the current approach, there's a clear differentiation between the intended targets for the header. Remember, these are instructions, not just debug info; having a single header with sometimes conflicting instructions for multiple components is... tricky.
>
>
> > 2) From the protocol point of view, CDNs are no different than any other intermediaries, so we should be providing a generic solution that works in modern cloud deployments with many layers of intermediaries, and not another special CDN-header. If we define common roles for all the peers, then we could have something like:
> >
> >   Cache-Control2: for=reverse_proxy; max-age=5, for=cdn; max-age=60, for=user_agent; no-store
> >
> > Thoughts?
>
> I have serious doubts about whether that's going to get implemented correctly, and I don't think the impetuous is great enough to make a *replacement* cc header viable (see: Set-Cookie2).
>
> 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?
>
> Cheers,
>
> * 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?
>
>
> >
> > Best regards,
> > Piotr Sikora
> >
> >
> > On Sun, Jan 17, 2021 at 6:45 PM Mark Nottingham <mnot@mnot.net> wrote:
> > [ document author hat on ]
> >
> > Hi everyone,
> >
> > We're requested time for discussion of this draft at the upcoming interim. We'd like the WG to consider adoption.
> >
> > Cheers,
> >
> >
> > > On 24 Nov 2020, at 1:01 pm, Mark Nottingham <mnot@mnot.net> wrote:
> > >
> > > FYI / for discussion.
> > >
> > >> Begin forwarded message:
> > >>
> > >> From: internet-drafts@ietf.org
> > >> Subject: New Version Notification for draft-cdn-control-header-00.txt
> > >> Date: 24 November 2020 at 1:01:02 pm AEDT
> > >> To: "Mark Nottingham" <mnot@mnot.net>, "Stephen Ludin" <sludin@ludin.org>, "Yuchen Wu" <me@yuchenwu.net>
> > >>
> > >>
> > >> A new version of I-D, draft-cdn-control-header-00.txt
> > >> has been successfully submitted by Mark Nottingham and posted to the
> > >> IETF repository.
> > >>
> > >> Name:                draft-cdn-control-header
> > >> Revision:    00
> > >> Title:               The CDN-Cache-Control HTTP Response Header Field
> > >> Document date:       2020-11-23
> > >> Group:               Individual Submission
> > >> Pages:               7
> > >> URL:            https://www.ietf.org/archive/id/draft-cdn-control-header-00.txt
> > >> Status:         https://datatracker.ietf.org/doc/draft-cdn-control-header/
> > >> Html:           https://www.ietf.org/archive/id/draft-cdn-control-header-00.html
> > >> Htmlized:       https://tools.ietf.org/html/draft-cdn-control-header-00
> > >>
> > >>
> > >> Abstract:
> > >>   This specification defines an HTTP header field that conveys HTTP
> > >>   cache directives to CDN caches.
> > >>
> > >>
> > >>
> > >>
> > >> Please note that it may take a couple of minutes from the time of submission
> > >> until the htmlized version and diff are available at tools.ietf.org.
> > >>
> > >> The IETF Secretariat
> > >>
> > >>
> > >
> > > --
> > > Mark Nottingham   https://www.mnot.net/
> > >
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>

Received on Tuesday, 26 January 2021 09:01:25 UTC