Re: Cache control in trailers?

Am 03.02.2021 um 11:46 schrieb Greg Wilkins:
>
>
> On Wed, 3 Feb 2021 at 01:43, Mark Nottingham <mnot@mnot.net
> <mailto:mnot@mnot.net>> wrote:
>
>     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.
>
>
> The problem with putting any kind of information like that in trailers
> is that you have to correctly end the body so that you can add any
> trailers at all.   This risks telling existing clients/caches that the
> body is complete and good.  So this feature does not work well if not
> implemented.
>
> Currently if a server has a problem whilst generating a response after
> the headers have been committed it does have several options for telling
> the client/intermediary it is abnormal:
>
>  1. not sending enough bytes if a content-length has been sent
>  2. not sending a terminal chunk if chunking transfer encoding is used.
>  3. reset stream in HTTP >= 2
>
> To put any error information in a normal trailer cannot be done in 1),
> and we invalidate cases 2) and 3)
>
> If you want to not break existing clients/intermediaries then you need a
> new feature to terminate a message abnormally, but with metadata saying
> why.   I think HTTP/2 already gives this in reset (at least to some
> extent), although you can send arbitrary trailers with a reset.
>
> For HTTP/1, you would need to have a way to abnormally terminate the
> response AND then provide trailers.
> ...

Chunk extensions come to mind (in theory we could send those and then
still abort the chunked response later on).

Best regards, Julian

Received on Wednesday, 3 February 2021 10:58:37 UTC