- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Mon, 28 Apr 2025 21:30:53 -0700
- To: Martin Thomson <mt@lowentropy.net>
- Cc: Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Apr 28, 2025, 9:16 PM Martin Thomson <mt@lowentropy.net> wrote: > > On Sat, Apr 26, 2025, at 13:05, Mark Nottingham wrote: > > 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. > > The domino effect seems pretty obvious here, but I think that the best approach would be to set expectations: only those resources that share one of the groups is affected. You don't then trigger invalidation logic again. Otherwise, incautious setup of groups could wipe your entire cache, which is a DoS attack recipe ingredient, if nothing else. If a resource is in multiple groups do all the groups trigger, or just one when invalidation happens? Right now we have it as all. But let's say we have a splash page showing prices of pool noodles and frisbees, and the price of pool noodles changes, so the origin knows that the group 'has-pool-noodle-price' is now invalid. The splash page getting invalidated would invalidate all pages with both, but really we want to be more selective. I regret not noticing this earlier, and of course 'purge-by-group' propertitary mechanisms solve this somewhat, so it isn't completely an issue. >
Received on Tuesday, 29 April 2025 04:31:12 UTC