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

I've addressed this with:
  https://github.com/httpwg/http-extensions/commit/dab5fd

> Note that further grouped invalidations are not triggered by a grouped invalidation; i.e., this mechanism does not "cascade."



> On 26 Apr 2025, at 10:34 am, 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. 
> 
> 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/
> 
> 

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

Received on Friday, 16 May 2025 05:08:04 UTC