Re: Cache control in trailers?

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