- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 26 Jun 2023 18:00:06 +1000
- To: Martin Thomson <mt@lowentropy.net>
- Cc: ietf-http-wg@w3.org
> On 26 Jun 2023, at 5:39 pm, Martin Thomson <mt@lowentropy.net> wrote: > > On Mon, Jun 26, 2023, at 13:44, Mark Nottingham wrote: >> The original design took the approach you suggest, but that makes error >> handling awkward -- if an unsupported selector type is used, should >> that be skipped, or should the entire thing fail (in which case the >> cache needs to scan it first)? > > Given that you have an up-front declaration of what is supported (which probably shouldn't regress), it seems like the odds of a failure of that particular type is unusual. It's up-front but out-of-band and also optional to implement/use. Even if it's relatively rare, we'd need to defined how those failures are handled for interior. > Besides, incomplete invalidation that produces a 4xx response doesn't seem like a major problem in this case. The client can try again with the offending chunk removed, or replaced with an alternative that is more likely to be supported. It depends on how expensive the invalidation is to process... Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Monday, 26 June 2023 08:00:16 UTC