Re: Cache control in trailers?

On Thu, 4 Feb 2021 at 10:33, Stefan Eissing <stefan.eissing@greenbytes.de>
wrote:

> I so far like the proposal from Willy the most. Especially as it has
> defined semantics in presence of unaware, merging intermediates.
>

It's really hard to work out exactly what proposals are on the table.  I
think everybody is not that far away, but arguing vigorously over little
differences.
There are several points I can see are:

   - General consensus that trailers are under utilized, but that there are
   various use cases for them and that defining a new mechanism may help with
   uptake.
   - There is a range of views on the scope: should there be a proposal
   just to make cache control possible in trailers or should it be a more
   general solution that includes status and other metadata.
   - Whatever the mechanism is, it should only be used if acceptable to all
   hops.  Not yet seen a concrete proposal for this.
   - Once the mechanism is used, there needs to be an indication at the
   start of the response that more info will be in the trailers. This can be
   done with a status (eg 3xx) or with 200 responses with new headers and/or
   header values.   I've not yet seen a proposal for using headers that
   addresses the problem of clients that don't know the new headers mistaking
   the 200 response as valid/complete.
   - There is a question of should the data only be in the trailers, or can
   it be sent in the headers and then changed in the trailers.
   - Once we get to trailers, will they use new headers or re-use already
   defined ones.

Then separately to how the mechanism indicates that there is more data in
the trailers, there is the need to well define the caching state machine
that will handle late and/or changed cache-control and/or status.

But while that list is moderately long, I don't really see any position
that far apart.     Perhaps a few more concrete drafts that address all
those concerns?

cheers





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

Received on Thursday, 4 February 2021 09:47:38 UTC