Re: Cache control in trailers?

Poul,

If there is a proposal to make trailers more palatable/usable by some 3xx
status code or some other signal in the header, then there is no need to
include some XOR mechanism. If servers want that kind of behaviour, then
they can come up with a new content type and send the nonce in the trailer.

The conversation here is really talking past each other.  The
original proposal is to support cache-control fields in trailers.  I don't
think anyone has said that is a really bad idea and most a
general supportive (although I'm a bit dubious on the use-case , but
recent posts have clarified that).  The counter is not that we shouldn't do
that, but that that trailers are generally not used and that there are some
proposals to make them more usable generally and not just for
cache-control.   So I see lots of actual agreement, but lots of posts like
there is disagreement???

So Mark... your original proposal was just about the Cache-Control field.
 Do you still think that it is only that field that needs support in
trailers?  What about Set-Cookie, Last-Modified, ETag, Retry-After, Age,
Expires, etc.   aren't these fields also affected by the use-case you have
outlined?   Do you still think a single field proposal is sufficient or is
a more general solution needed?

cheers





On Fri, 5 Feb 2021 at 08:51, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> --------
> Willy Tarreau writes:
>
> > > Which is *precisely* why I propose we give the server the option
> > > to XOR scramble the body until the metadata is ready.
> >
> > No please Poul-Henning, really please, no more addition of such horrors
> > that we had to deal with in WebSocket. It serves no purpose and prevents
> > anyone along the chain from efficiently processing the contents,
> including
> > but not limited to, H1<->H2 translation, compression, inspection, etc.
>
> First, note that if your downstream understand this new extension, nothing
> prevents you from forwarding in a streaming fashion and leaving the XOR'ing
> to the next sucker in the chain.
>
> Second: Yes, that is *precisely* why I want to offer servers that
> option:  So they have a sure-fire way to prevent sneak-peeks which
> they have reason to belive will get things wrong.
>
> --
> 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.
>


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