Re: Cache control in trailers?

Hi,

Well if there an error then going to have to be a signal to indicate a
change, ideally if an error occur I would preferable want to push a full
new response, and headers to avoid a redirect, the action in my mind should
invalidate the whole previous response headers and body. Should be
basically deleted. Then new response body would need to include a new url
for the pushed response, to replace the current page.
I think of it like an implicit embedded redirect. So in my mind there is
first a Control signal quick, then receipt of a new full response http
response that is pushed and mabye could then follow by a redirect push, if
possible not sure that possible. Where if control signals failed, then
local client, would need decided, which parts are still valid for caching.

In which case revalidation of some chucks already receive that could have
been cached need to revalidate. But I need catch up here, but in my mind I
want partial chucks, to be able revalidate using hash or best new
equivalent.
Don't want to fully redownload a file of a few gigs.
For each chuck received, were just the streaming chucks need revalidate
there hashes.. I haven't done deep dive here.

In essence, cache being setup, to must immediatly revalidate, but can mabye
display stale content, in the mean time, like error page that previously
transmitted, then browser saying attempting or trying again, that be like
at browser page level management.

Woundering for fetch, benift from somthing like that, but then fetch would
need to be able have another call back, to signal it to refetch content as
been updated. This allow mabye display old unavailable content while
fetching the new. So for like this to work need another call back to signal
it.

Mabye http header could be used to indicated support for return stale error
page, while revalidation.

Just my too cents. But not having to buffer response is going to be great
improvement for memory pressure on server and overhead and time till first
packet recieved.

My two cents but have my previous proposal of optermistics response
previously.

Kind Regards,

Wesley Oliver

On Wed, 03 Feb 2021, 02:44 Mark Nottingham, <mnot@mnot.net> wrote:

> Hi all,
>
> One of the fundamental limitations of HTTP that people often bump into is
> that the status code and headers precede the body,[1] so if something goes
> wrong while the response is being generated, they can get into awkward
> situations.
>
> For example, if server-side script has made the response cacheable and
> encounters an unrecoverable error while generating it, that response will
> get stored and reused by downstream systems.
>
> Right now, the only ways for it to avoid this is (a) buffer the whole
> response, (b) don't ever make the response cacheable, in case an error
> occurs, or (c) purposefully truncate the response (i.e., cause a protocol
> error), hoping that all downstream caches correctly avoid storing
> incomplete responses.
>
> None of these seem like great options.
>
> One better way would be to indicate the error in trailers. This has been
> mused upon before, e.g., allowing the status code to occur in trailers --
> but that is likely unworkable, because all of the potential effects of a
> different status code can't be accounted for when trailers are received.
>
> A more limited approach would be to focus just on the cache's behaviour --
> e.g., to allow Cache-Control: no-cache in trailers,[2] updating the
> semantics of the response to make sure that it's revalidated before it's
> reused.
>
> What do folks think - would this be useful? Obviously it would need to be
> implemented in browsers and other caches.
>
> Cheers,
>
> 1. Or is that 'content' now?
> 2. Note that we don't have to reuse CC: no-cache; it could be that a new
> trailer communicates what's intended more clearly.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>