Re: Cache control in trailers?

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.

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.

(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.)

David