- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 3 Feb 2021 14:05:38 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
On Wed, Feb 03, 2021 at 12:38:36PM +0000, Poul-Henning Kamp wrote: > -------- > Willy Tarreau writes: > > On Wed, Feb 03, 2021 at 12:22:54PM +0000, Poul-Henning Kamp wrote: > > > > But it's not about a marginal speed up here, it's about a server not being > > > > certain whether it wants its data to be cached or not until they're complete > > > > > > And that's fine! > > > > > > What I'm proposing is making it possible for the server to say "Please grab > > > this body first, then I'll tell you what it means afterwards." > > > > > > The marginal speedup we loose because the recipient cannot act on > > > the body until they see the trailers is regrettable, but we stil > > > reap the overlap of production and transmission. > > > > 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. > with my proposal we can at least overlap the transmission and the production. > > > > The risk of getting two different Cache-Control headers is pretty much > > > precisly why trailers are not being used. > > > > Note that I purposely asked that we do *not* use the same header name, > > And I'm saying: Just dont send the preliminary cache-control to begin with: It's not worth it. 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. Willy
Received on Wednesday, 3 February 2021 13:05:58 UTC