Re: Two new HTTP caching specifications

Hi Evert,

The tagged approach is more intuitive for most, as shown by its wide usage across multiple CDNs (from the top of my head, Akamai, Fastly, Cloudflare, and I think Cloudfront all do it this way).

Also, putting this information in the link header requires intermediaries to parse the link header, which they're reluctant to do for performance reasons; it's syntactically complex, and used for many purposes besides this one.

Cheers,


> On 21 Jul 2023, at 1:19 pm, Evert Pot <me@evertpot.com> wrote:
> 
> 
> On 2023-06-25 00:48, Mark Nottingham wrote:
>> HTTP enthusiasts,
>> 
>> I've just published -00 drafts of two new specifications.
>> 
>> - HTTP Cache Groups <https://datatracker.ietf.org/doc/draft-nottingham-http-cache-groups/>
>> 
>> "This specification introduces a means of describing the relationships between stored responses in HTTP caches, 'grouping' them by associating a stored response with one or more opaque strings."
>> 
>> 
> Some years ago we adopted Linked Cache Invalidation, which you are also a co-author on:
> 
> https://datatracker.ietf.org/doc/html/draft-nottingham-linked-cache-inv-04
> 
> We use this to solve the same problem. The main difference appears to be that it uses an existing header (Link) and instead of string keys, it uses URIs to identify and invalidate groups.
> 
> I like the URI mechanism, because caches are already indexed by URI, so a given resource can effectively say: "My cache is expired when resource X expires". One advantage is that we don't need a secondary key. 
> 
> So I'm curious why you took this direction over the original idea using Links.
> 
> Evert
> 
> 

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

Received on Friday, 21 July 2023 20:24:32 UTC