Re: Cascading invalidations (draft-ietf-httpbis-cache-groups)

> On 26 Apr 2025, at 12:11 pm, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> Wait, what? (checks draft) ... huh.  This is strange.
> 
> I thought we are defining a mechanism that operates similar
> to cache tags, in which cached responses are invalidated based
> on their membership in one or more sets.
> 
> The Cache-Group-Invalidation header field specifies what sets
> to invalidate. It should be irrelevant that a response is also
> a member of other sets. The same should be true of other APIs.
> 
> Color me confused. Do you have a use case for this?

It surprised me too, but it's a reasonable reading of the current spec. The problem is that -- by necessity -- we don't specify or constrain what the source of invalidations might be, and that can be read to include invalidations *caused* by group membership.

> I have no use for an entire group of cached responses to
> self-invalidate just because one response in the same group
> becomes invalid (for any reason). The only time I want a group
> of responses to be marked invalid is when I call specifically
> for that group of responses to be invalidated.
> 
> If I wanted more invalidations, I would have indicated more
> groups or a larger parent group in the API/header field.
> In other words, never cascade, IMO.

Personally, I agree, but I wanted to hear from others too.

Cheers,


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

Received on Saturday, 26 April 2025 03:05:58 UTC