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

> On Apr 25, 2025, at 5:34 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Everyone,
> 
> Per Med's feedback below, we should decide whether an invalidation triggered by a group association can/should/must trigger invalidations "downstream".
> 
> For example:
> 
> Cached response 1 has group list of [a, b, c].
> Cached response 2 has group list of [c, d, e].
> Cached response 3 has group list of [e, f, g].
> 
> Let's say there's an API call to invalidate response 1. Because they're both in group 'b', both responses 1 and 2 will be invalidated.

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?

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.

> This text in the current spec:
> 
>> A cache that invalidates a stored response MAY invalidate any stored responses that share groups (per Section 2.1) with that response.
> 
> ... can be read to mean that because response 2 is invalidated and is part of group 'e', response 3 can also be invalidated because it's also part of that group.
> 
> Because it's a MAY, this is optional -- effectively, each implementation will decide whether it will cascade invalidations like this. As a reminder, it's a MAY because we can't introduce new requirements onto already-deployed caches, and the source of invalidations is potentially quite diverse.
> 
> If we wanted to, we could make this more strict, and say that an invalidation caused by a grouping is not a trigger for further group invalidations.
> 
> I suspect the effect of doing so would be to normalise expectations about how this mechanism operates. However, per above the sources of invalidations are already diverse -- it might be through the mechanism defined in RFC9111 (invalidation as a side effect from POST etc.), it might be a proprietary API call into a CDN or reverse proxy cache, it might be using the header defined in this specification, and so forth.  So it's not clear how much this would practically improve interop.
> 
> We could also go in the other direction and say that if a cache implements this draft, it MUST cascade invalidations. That would also produce better interoperability, but may be impractical for some implementations to implement, and could cause efficiency / load concerns (or even be an avenue for attack).
> 
> The simplest option would be to just note that invalidations _can_ cascade, but that implementations aren't required to do so.
> 
> What do people think?

I suggest deleting section 2.2.1 and specifying them as named sets.

The invalidation mechanism provided is invalidating sets.
I have no reason for that to cascade, ever, since the caller
can specify all of the sets they want invalidated.

Of course, it's also true that a cache may choose to invalidate
any cached response, any time it feels like doing so, so expressing
a requirement this way seems like bad form. Perhaps it would be
easier to write "A cache compliant with this specification
MUST ...".

A response that just happens to be invalidated, for some other
reason than the mechanism defined here, should not have an
impact on other members of the sets to which it belongs.
This would be normal, everyday behavior, whereas set invalidation
is something I'd only want done by authenticated command.

....Roy

Received on Saturday, 26 April 2025 02:11:58 UTC