- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 5 Feb 2021 10:09:34 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Adrien de Croy <adrien@qbik.com>, Greg Wilkins <gregw@webtide.com>, Stefan Eissing <stefan.eissing@greenbytes.de>, Ryan Sleevi <ryan-ietf@sleevi.com>, Martin Thomson <mt@lowentropy.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Fri, Feb 05, 2021 at 07:51:47AM +0000, Poul-Henning Kamp 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. The problem is that we all know that breakage is never black or white, it's always gray in that non-compliant intermediaries get stuck in the middle with something that desynchronizes them, or worst, get attacked by some body placed at a location where they were expecting some headers. Willy
Received on Friday, 5 February 2021 09:10:07 UTC