- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 27 Aug 2021 12:16:31 +1000
- To: Martin Thomson <mt@lowentropy.net>
- Cc: ietf-http-wg@w3.org
> On 27 Aug 2021, at 12:12 pm, Martin Thomson <mt@lowentropy.net> wrote: > > 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. 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) > On Fri, Aug 27, 2021, at 12:06, Mark Nottingham wrote: >> <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/ >> >> >> > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 27 August 2021 02:16:49 UTC