Re: Cache control in trailers?

> On 3 Feb 2021, at 12:17 pm, Martin Thomson <mt@lowentropy.net> wrote:
> 
> In my experience, these dynamic creation processes use chunked encoding, so you can have a well-formed (from an HTTP sense) body.  The content might be utter garbage though, despite what the headers might have said.

... or the content could be 'sorry, an error happened' -- but with a long cache policy.

> The usual way of dealing with this is buffering the entire response, which is obviously unpleasant.  In h2 or h3, stream resets are probably the best option.  In h1, tearing the connection down also seems preferable.

I think the use case is 'I want to convey a well-formed body that reflects the error state as best I can, and have the client show it to the user, but I changed my mind on the caching policy due to the aforementioned error.'

Stream resets and tearing the connection down *might* work, but they're not great solutions, because they can also indicate other problems, and some clients might act differently.

> Mark, would you expect a client to signal its willingness to respect this signal?  I'm thinking that is more important a question to answer than whether to use Cache-Control.

I think requiring a signal would make this impractical; no one is going to decide to buffer because they don't get the signal.

I think this could be deployed incrementally; e.g., a CDN could support it so as to limit the damage to other clients. Once enough browsers support it, it would probably be good enough for general use -- which makes browser implementation important.

Since I mentioned CDNs, it occurs that if we adopt CDN-Cache-Control, it'd be useful to have a discussion about whether making *any* cache-control header in a response such a signal is the right approach, or whether having a separate header as a signal is better. I do think that confining the signal to its effects on caches is a better approach than a general signal, however.

If the signal is Cache-Control, it's also worth discussing whether there's a viable use for other directives -- e.g., updating max-age after you send the response body. For content aggregation tools like ESI (and more modern successors, which there seems to be a lot of interest in, thanks to edge computing), I suspect this could be helpful. Again, it's much more useful if it gets into browsers.

Cheers,


> 
> On Wed, Feb 3, 2021, at 12:08, Ben Schwartz wrote:
>> If adding trailers requires the body to be well-formed, then this would 
>> seem to preclude option (c), so this could not be used to indicate an 
>> error.  It would only apply to cases where the body is correct and 
>> usable but less cacheable than expected, which seems like a very narrow 
>> use case.
>> 
>> On Tue, Feb 2, 2021 at 7:43 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/
>>> 
>>> 
>> Attachments:
>> * smime.p7s
> 

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

Received on Wednesday, 3 February 2021 01:38:05 UTC