Re: Cache control in trailers?

--------
Greg Wilkins writes:

>    - 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.

The current definition of trailers, the one nobody has wanted to
touch with a ten feet pole for 25 years, has metadata in both headers
and trailers, and that is the primary, almost the sole reason, people
cite for not supporting trailers.

We can cling to that, for what seems at best marginal or even
speculative benefits, and trailers will continue to not be used,
or we can get rid of that, and they may stand a chance.

The downside is that no semantic processing can happen downstream,
until both the body and trailers have arrived, but that is still
significantly faster than having the server buffer until the response.
is complete.

>    -Whatever the mechanism is, it should only be used if acceptable to all
>     hops.  Not yet seen a concrete proposal for this.

No matter what kind of "magic marker" we use to enable an extension,
there will be buggy-proxies out there which let the marker through,
yet do not understand what they just consented to handle.

Willy's proposal to strike a middle ground is sympathetic:  Formulate
responses in such a way that buggy implementations will handle them
safely, for instance by a boiler-plate "neutering" Cache-Control
in the headers.  Unfortunately that just postpones the trouble until
the buggy-proxy attempts the next transaction on the connection and
barf on the orphan trailers.

I can only imagine two mechanisms that can /eliminate/ buggy-proxies mangling things:

1.  Break the on-wire format enough that buggy-proxies will reject
    the response as broken.

2.  Scramble the body with a nonce only available in the trailers,
    so that clients will never see good data if the trailers did not survive.

There seems to be little appetite for number one, so maybe we should
talk about #2 ?

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

 (Optional:  Allow other headers but only if they are listed in the Connection header)

 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).

-- 
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 10:53:53 UTC