Re: Cache control in trailers?

On Mon, Feb 08, 2021 at 11:11:39AM +0000, Poul-Henning Kamp wrote:
> --------
> Willy Tarreau writes:
> > On Mon, Feb 08, 2021 at 08:51:51AM +0000, Poul-Henning Kamp wrote:
> > > --------
> > > Roy T. Fielding writes:
> > > 
> > > > Please, if there is something specifically wrong with the current definitions
> > > > of Trailers in the specs currently in WGLC, [...]
> > > 
> > > There is, take for instance 6.5.1:
> > > 
> > > 	Many fields cannot be processed outside the header section
> > > 	because their evaluation is necessary prior to receiving
> > > 	the content, such as those that describe message framing,
> > > 	routing, authentication, request modifiers, response controls,
> > > 	or content format.
> > > 
> > > The unstated assumption is that the recipient cannot be required to
> > > spool up the body and wait for the trailers before doing anything
> > > with it.
> >
> > ... and watch the whole Web collapse because suddenly everyone
> > needs to buffer every byte in flight before even knowing where to
> > forward it if at all.
> > [rant]
> > But let's not suddenly declare that everything would be
> > better at the end because this is utterly wrong.
> 
> Nice strawman, but nobody has advocated anything like that.

This is still the way I read it: "buffer body before processing headers"
will almost always mean "store and forward".

> Now, if you have any considered opinions on offering *an extension*
> which allows all *semantic metadata* fields be put at the end, I'd
> love to hear them.

No I don't because I think it is not a good idea. Supporting *some*
may make sense but definitely not all, and not in all cases, as there
are always useful information there that are better retrieved before
the body. For example, if you pass Content-Type too late, you may
lose the opportunity to perform compression on the fly.

Maybe we need to implement something between TE and Trailers so that
the client could suggest the server to place certain fields in the
trailer part. This would obviously be a per-connection header field.
But as to why a client would ask for these beyond the rare examples
already suggested seems unclear to me.

Willy

Received on Monday, 8 February 2021 12:41:49 UTC