Re: Cache control in trailers?

Hi,

The other thing I tought of is that an generic error page could be
spesified in the first response headers, so if fail to push and dynamic
more spesific error page. A generic static one could be fetchee for
display, mabye js could pass error codes or response pushed to enhance it
with clientside fecth.

But any error that so fatal that error page couldn't be pushed, then
reverted to the error page to display that spesified in the response
headers.

I think like the idear of first eesponse header for an error page to show
if fatal.

Guess in this case, may want fatal page to be able fetch old url, which
errors, so interigate the url, mabye some headers or title improve its
messages. So like browser client would pass url of fatal page to that as
param to the error page.

In this case one would want to be able to fetch old failed response, to
display correct failure details, so want fetch to be able to fetch the old
failed url from the static fatal page, that redirect to.
So mabye a header for fetch, to choose what to serve from cache while
revalidation and then another status, saying response been revalidated.

That way a static page with fetch, provide a nice error page show details
by interogating previous failed fetch and wait for revalidation, in which
it could redirect and recover immediately. So might see fail page like for
a second then show second successfull attempt, that went off during the
error page display, that caused the revalidation and on success a redirect,
happing locally, based in cache.

Just think is one able to return cache item I'd, such that prevent 3rd
revalidation and fetch, if no content expire was sent, as redirect then
won't be a local cache hit.

I like idea spesify error page in the response header, as if fails
critical, can push dynamic error response page.

But definitely need cache to require forced revalidation.

Kind Regards,

Wesley Oliver

On Fri, 05 Feb 2021, 20:13 Wesley Oliver, <wesley.olis@gmail.com> wrote:

> 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/
>>
>>
>>