Re: Cache control in trailers?

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

-- 
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 12:38:49 UTC