Re: Cache control in trailers?

> On 5 Feb 2021, at 4:17 am, David Benjamin <davidben@chromium.org> wrote:
> 
> On Wed, Feb 3, 2021 at 7:04 PM Mark Nottingham <mnot@mnot.net> wrote:
> 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.
> 
> Ah, I see. The original email mentioned an unrecoverable error, so I interpreted this to mean the script is unable to properly service the request.

Aha - my apologies for the imprecision.

> Are you saying that the script, despite the error, is still able to generate a passable, but suboptimal, response to the request? Could you give an example? Is the server simply truncating the HTML and doing something cleverer? I would think that, if you've gotten far enough to start streaming output, your ability to change gears is somewhat limited.

Absolutely. A common architecture when you have to scale is to use a thin "front-end" layer to assemble responses from back-end HTTP APIs, with generous lashings of caching. This is the function of ESI[1], it was the approach we used in many Yahoo! properties back in the day, my understanding is that much of Amazon is built this way, and emerging "edge computing" architectures[2][3][4] can be used in this fashion as well. There's also a fair amount of interest in using this approach client-side in various ways.[5]

In doing so, you necessarily have to handle failure in one or more of those service calls. ESI, for example, allows you to use a backup URL or text (depending on whose extensions you're using) to paper over the problem.[6] That makes the response complete, and it serves that client as best as it can, but you wouldn't want to cache the result for reuse.

To date, this problem hasn't been a dealbreaker because most use of this approach has been for personalised or otherwise dynamic content -- the inputs are cached, but the output isn't cacheable (or when it is, it's private). However, I'm recently hearing of more uses where output caching is desired, because people find this kind of architecture beneficial for more than that.

> (For HTML and browsers, a stream reset won't unload the document or anything. I suspect a stream reset would still work fine there. We handle truncated bodies differently in different contexts.)

Understood. That's one of the reasons I don't want to use it as a signal; it isn't explicit.

Cheers,


1. https://www.w3.org/TR/esi-lang/
2. https://www.fastly.com/products/edge-compute/serverless/
3. https://workers.cloudflare.com
4. https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
5. https://symfony.com/doc/current/templating/hinclude.html
6. A lot of effort is often put into making sure that the engine can stream as much as it possibly can while still reserving the ability to dynamically handle problems like this. It's Hard[tm].

--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 4 February 2021 23:51:07 UTC