- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Feb 2021 11:04:13 +1100
- To: David Benjamin <davidben@chromium.org>
- Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, Willy Tarreau <w@1wt.eu>, Martin Thomson <mt@lowentropy.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Hi David, > On 4 Feb 2021, at 9:58 am, David Benjamin <davidben@chromium.org> wrote: > > In addition to the state machine issues Ryan points out, I don't think the original premise in focusing on just the cache's behavior holds. > > Suppose a server has encountered an unrecoverable error generating a resource. The cache must know for future requests, but the current request also must know. Truncated and complete bodies are different. Truncated downloads may be communicated to the user as failed. Truncated script and style resources do not execute because doing so has security consequences. > > Resetting the stream sends exactly the signal you need. Doing anything else in the HTTP frontend is a bug, likely with security consequences. Likewise, an HTTP cache failing to notice the reset is a bug, likely with security consequences. If some HTTP cache is broken here, it'll need a code change for Cache-Control trailers anyway. That code change is better spent on fixing this bug. That's explicitly not the case I'm trying to address here -- what I'm interested in is the case where there is a _recoverable_ error, but it isn't desirable to reuse the resulting response on the same terms as was optimistically thought when the headers were sent. Usually, this will be in generating HTML. If an unrecoverable error is encountered, resetting the stream is indeed the right approach. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 4 February 2021 00:04:35 UTC