Subject: #1605: Targeted CC as a trailer?

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Aug 2021 12:06:58 +1000

<https://github.com/httpwg/http-extensions/issues/1605>

We recently had a fairly long discussion about whether we could define Cache-Control as a trailer, so that caching policy could be updated after content is sent. We concluded that there wasn't yet enough interest or alignment to pursue specification work there.

I've raised this issue for Targeted Cache-Control to see if there's any interest in defining it for these headers. For example, a CDN or reverse proxy could support trailer updates of caching policy when targeted specifically at them. 

From a specification standpoint, we could do that by explaining how it would work, but requiring the specific header field definition to explicitly opt into being valid in trailers. I'd say CDN-Cache-Control wouldn't do this, but other fields could.

Alternatively, we could leave the spec as-is, and allow individual headers to specify how they do this. The potential issue there is that they might divert in doing so.

Are folks (especially those who have a cache implementation) interested in this?

Cheers,

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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Aug 2021 12:12:46 +1000

Isn't the primary advantage of x-cache-control that it behaves just like cache-control?  This would create inconsistencies that would make it harder to adapt to different values of "x".  I would prefer to see a general solution.

On Fri, Aug 27, 2021, at 12:06, Mark Nottingham wrote:
> We recently had a fairly long discussion about whether we could define 
> Cache-Control as a trailer, so that caching policy could be updated 
> after content is sent. We concluded that there wasn't yet enough 
> interest or alignment to pursue specification work there.
> 
> I've raised this issue for Targeted Cache-Control to see if there's any 
> interest in defining it for these headers. For example, a CDN or 
> reverse proxy could support trailer updates of caching policy when 
> targeted specifically at them. 
> 
> From a specification standpoint, we could do that by explaining how it 
> would work, but requiring the specific header field definition to 
> explicitly opt into being valid in trailers. I'd say CDN-Cache-Control 
> wouldn't do this, but other fields could.
> 
> Alternatively, we could leave the spec as-is, and allow individual 
> headers to specify how they do this. The potential issue there is that 
> they might divert in doing so.
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Aug 2021 12:16:31 +1000

> On 27 Aug 2021, at 12:12 pm, Martin Thomson <[email-masked]> wrote:
> 

This doesn't change the behaviour so much as it adds to it, I think. The semantics of the cache directives would be the same, as would the syntax of the field; it only has additional semantics when it occurs in a trailer.

(I somewhat suspect that there isn't going to be immediate interest in this one, which means we're likely to punt it, but I thought I'd ask and perhaps be surprised)

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Aug 2021 12:19:24 +1000

On Fri, Aug 27, 2021, at 12:16, Mark Nottingham wrote:
> This doesn't change the behaviour so much as it adds to it, I think. 

An addition is also a change.  Anyone that comes to depend on the trailer-based behaviour would be more dependent on the CDN that supported that behaviour if alternative providers did not.  That's the source of my concern.  Of course, CDN-proprietary extensions likely fill this gap, so I recognize that not doing this is not necessarily a real solution.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Aug 2021 12:22:12 +1000

> On 27 Aug 2021, at 12:19 pm, Martin Thomson <[email-masked]> wrote:
> 

As I said, we wouldn't define this for CDN-Cache-Control; it's only for fields that explicitly opt into it. 

For example, if BunnyCDN wanted to support trailer updates, they could say so in their documentation for (presumably) BunnyCDN-Cache-Control. 

The question here is whether *they* define it in that document completely -- with the possibility of mismatches with other implementers who make that choice -- or whether we define it here so that they can reference the standardised (yet optional, opt-in only) behaviour.