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

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. 

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?


> On 20 Apr 2025, at 6:39 pm, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> # Cascaded effect
>> 
>> If we have an entry that belongs to A/B, another that belongs to B/C, and a
>> third to C/D. If A group is invalidated, this will impact the second entry per
>> the rules in 2.2.1. However, does this impact the third one as well is it
>> shares a group with the second invalidated one?
> 
> This is an interesting question. It's reasonable to assume that *any* invalidation (including that triggered by a group invalidation) is eligible, but some implementers may reasonable wish to avoid allowing such a 'cascade' for efficiency reasons.
> 
> I tend to think that we should explicitly specify that an invalidation triggered by a group invalidation does NOT trigger group invalidations itself; i.e., there is no "cascading." 
> 
> What do others think?


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

Received on Saturday, 26 April 2025 00:34:18 UTC