Re: Cache control in trailers?

------ Original Message ------
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>


>--------
>Greg Wilkins writes:
>>  --0000000000001c746805ba8386a3
>
>>  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.
>
>Because I want to keep it simple.
>
>>  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
>
>That is what we have today, and nobody wants to touch that with a ten feet pole.
>
>>          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 [...]
>
>The benefit is that the sender can trust that the content will not be
>interpreted until it has been "released", and that we can trust buggy
>proxies to make such a hash of it (pun intended) that it will be
>found and fixed.

at the cost of the ability to block on any metadata without having to 
spool the entire resource (and delay it).

this is a non-starter as far as I'm concerned.

Some fields belong only in the headers and should never be seen in 
trailers.  I would rather see clarity around this.  E.g. any Content- 
field belongs in the header only.

Isn't there a warning field that can be used for more general cases?

Adrien


>
>
>--
>Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>phk@FreeBSD.ORG         | TCP/IP since RFC 956
>FreeBSD committer       | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.
>

Received on Thursday, 4 February 2021 23:30:44 UTC