Re: Cache control in trailers?

On Wed, 3 Feb 2021 at 01:43, Mark Nottingham <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.



-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com