Re: Cache control in trailers?

On Wed, Feb 03, 2021 at 02:40:27PM +0000, Poul-Henning Kamp wrote:
> --------
> 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.

But why do you say "nobody" after I gave an example (gRPC). You don't
necessarily *need* to merge them, just like some headers are forbidden
in trailers, we can very well specify that some fields are only relevant
in trailers. FWIW apparently gRPC does this as I seem to have read
somewhere that a grpc-status trailer is mandatory and that as a corollary,
you may never see an H2 data frame carrying the ES flag.

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

It depends what we want to do. Mark mentioned he wanted to make sure
this truncated response is not cached. Just emitting a preliminary
cache-control disabling caching does serve this purpose.

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

The problem is that even a 100% compliant intermediary will have great
difficulties parsing a body on a 1xx :-/

Willy

Received on Wednesday, 3 February 2021 15:10:22 UTC