- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Sat, 24 Jun 2023 22:54:56 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Dear Mark, I read your first draft and found it simple and clear. 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. 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. 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. 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. Sincerely, Watson -- Astra mortemque praestare gradatim
Received on Sunday, 25 June 2023 05:55:13 UTC