- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 25 Jun 2023 19:06:53 +1000
- To: Watson Ladd <watsonbladd@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Watson, > On 25 Jun 2023, at 3:54 pm, Watson Ladd <watsonbladd@gmail.com> wrote: > > Dear Mark, > > I read your first draft and found it simple and clear. Thanks. > I do however > have some questions about how changes in groups are supposed to be > processed: if items A and B share a group, but later the group of item > B is changed, a revalidation of A might spuriously cause a > revalidation of B, despite the server having changed the group > associated with B. The cache would have no way to know that happened. An invalidation sourced from a response should only be applied on a state-changing request, so I don't _think_ this is an issue. > On the second draft I do have a quibble with the purge option. In a > CDN with many servers, some of which may be down for various reasons, > it may not be possible to effect a purge for a considerable period. > While the servers that are down will be cleared of cache data before > returned to service, the purge isn't complete until then. Some CDNs > may have architectures where a very expressive purge request is > processed via broadcast with no discernable feedback on its execution > until much longer. The guarantees given by CDNs (and others) vary widely; some are best-effort, others are reliable. I think it might be worth trying to characterise this in the description format, but we'd need to do so in a way that could actually be used by applications. > It seems that the addition of revalidation to groups is a change from > the current tag or surrogate key mechanism some CDNs have, where a > response has identifiers that can be used in a purge but there is no > shared revalidation. It might be worth exposing just the current tag > structure in the invalidation draft, and then let the group draft > define an extension. Yes, that's a new mechanism -- it definitely needs some discussion before shipping anything. Intriguing but untested (compared to most of the rest). > Lastly, and I know these drafts are at an early stage, I think you > want an IANA registry for the methods so that this can be extended. Yep! Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Sunday, 25 June 2023 09:07:04 UTC