Re: Cache control in trailers?

On Thu, 4 Feb 2021 at 11:53, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> Here's a strawman:
>         A new 3xx response code which means: "Everything is in the
> trailers."
>         The allowed header fields:
>                 Transfer-Encoding: chunked
>                 Content-Length
>                 Connection
>

Why everything in the trailers?  Isn't it sufficient to say that
authoritative fields are in trailers and that any in the header should be
considered just hints.

Isn't entirely dependent on the fields themselves? Some will make sense to
only be in a header (eg Content-Length, Transfer-Encoing), some might only
be practical in a trailer (checksums), others can be in either place but
would be nonsensical to have them in both (eg Content-Type can't change mid
way through the content), others can be in both places and it may make some
sense for the value to change (eg Cache-Control, :Status, Set-Cookie )

Fields like Date, Retry-After, Age, Expires, Last-Modified might well
benefit from being set in the header and then updated in a trailer if the
transmission took a long time.  A strong ETAg might be able to be generated
on the fly an added to the trailer

All the Accept- fields don't make much sense in a trailer as they relate to
what the server will accept on other requests which may be concurrent with
the transfer.

I can't see why any Content- field should change or not be known during the
header generation.  I can see content becoming invalid, but that is a
change of status and not a new Content- field

So I'm not seeing a good reason that a mechanism should only apply to
Cache-Control, because there are at least a few other related fields that
areq equally applicable to change as Cache-Control (Date, Retry-After, Age,
Expires, Last-Modified).     But on the flip side, I'm not seeing many
fields other than those that are related to caching in some way that are
applicable.

So a thorough enumeration of all the fields is really needed to justify why
add a mechanism for just one field or for a subset or for all.


        The sender XOR scrambles the body with a N*64bit randomly chosen
> nonce.
>         The nonce is disclosed in a "Trailer-Nonce" field (as RFC8941 Byte
> Sequence).
>

I'm not seeing the benefit of this other than if you really want to melt
the polar ice caps with wasted CPU cycles.  If we can't trust endpoints to
interpret the mechanism correctly, then we may as well invent a new
protocol.

cheers







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