- From: Martin Thomson <mt@lowentropy.net>
- Date: Fri, 27 Aug 2021 12:12:46 +1000
- To: ietf-http-wg@w3.org
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: > <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/ > > >
Received on Friday, 27 August 2021 02:13:17 UTC