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

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 01:36:19 UTC