Re: Cache control in trailers?

+1

seems like a much more robust strategy


------ Original Message ------
From: "James M Snell" <jasnell@gmail.com>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 4/02/2021 4:32:59 am
Subject: Re: Cache control in trailers?

>One of the likely challenges here is that if a failure happens during
>the transmission of the response the server may not even be able to
>add a trailer.
>
>Just musing on a slightly different approach... what if we could have
>a Cache-Control directive that says, "Only cache if a given trailer is
>received (signaling success)".
>
>In the response headers we'd have...
>
>   Cache-Control: cache-on-trailer
>
>Then, only at the end of a successfully transmitted response we'd have
>the trailer:
>
>   Cache-Control: cache-commit
>
>The assumption here would be that if the commit trailer is not
>received the assumption is that the response should not be cached.
>
>Sorry if this is a repeat or rehash if it's already been discussed, I
>haven't had the time to go through the discussion thread.
>
>- James
>
>On Tue, Feb 2, 2021 at 4:44 PM 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/
>>
>>
>

Received on Wednesday, 3 February 2021 21:45:02 UTC