Re: Cache control in trailers?

--------
Willy Tarreau writes:

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


First, again: In any situation where the authoritative headers are known
at header tranmit time, one would be stupid not to send them as headers.

Second: Only if your job *is* to forward, you have heard of browsers, right ?  ;-)

Third: The *only* use-case we are talking about is when authoritative
headers are not available until after the entire body has been produced.

In that case it will be faster if the body can be transmitted as it
is produced, followed by the headers, than to spool up the body
on the server, and send it after the headers.

> For example, if you pass Content-Type too late, you may
> lose the opportunity to perform compression on the fly.

I have no problem with Content-Type being in the headers or in the trailers.

My problem is when it is in both and they disagree.

Or when it takes complex semantic editing to join two wildly differing
Cache-Control headers.

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

Another bogus straw-man, as you yourself note: The need for this
arises on the server side, the client as no idea if any particular
object will be subject to such issues or not.

-- 
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 Monday, 8 February 2021 13:54:03 UTC