- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 03 Feb 2021 14:40:27 +0000
- To: Willy Tarreau <w@1wt.eu>
- cc: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
-------- Willy Tarreau writes: > > > It's not just a loss of speed up, but the inability to reject it or > > > process it. You can't even know how it's encoded, if you need to > > > decompress it on the fly. > > > > Yup, and that's too bad. > > > > Today the server has to buffer the body it before it sends the headers, > > Not if it uses chunked encoding, which was precisely made for this. Except it doesn't work, because nobody implements trailers - because they dont want to deal with the complexity of merging headers and trailers. Also, chunked doesn't help you any with the "Oops, production crapped out half way through..." scenario, where you want to make it a 50x instead of 2xx. > I get your point, but it might make sense to make sure the response > is *not* cached by opportunistic caches on the path if the goal is to > ensure that only totally valid responses are ever cached. Yes, absolutely. That's why my initial mockup was structured to make sure such caches wouldn't even consider the response valid, should they by mistake get one. -- 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 Wednesday, 3 February 2021 14:40:44 UTC