Re: Cache control in trailers?

--------
Willy Tarreau writes:
> On Wed, Feb 03, 2021 at 09:44:10AM +0000, Poul-Henning Kamp wrote:
> > --------
> > Martin Thomson writes:
> > > On Wed, Feb 3, 2021, at 19:22, Poul-Henning Kamp wrote:
> > > > If we want enable that, we should move *all* headers and status to the 
> > > > trailer, so that no confusion is possible.
> > >
> > > Oddly, I agree, though this comes with a whole lot of problems with message processing at intermediaries and whatnot.
> > 
> > I'm not sure I see any _major_ problems.
> > 
> > If the client has indicated it can do 142, a non-policy intermediary can just
> > pass stuff along, and that realizes the full production/transmission overlap.
>
> Please, look at what I proposed before, consisting in letting the origin
> server mark the response as non-cacheable first, and announcing that this
> might change in the trailers.

I did, that is actually what gave me idea for my proposal :-)

The problem with trailers has always been that people get hung up over the marginal potential speedups if we allow things to "change later".

But no software in the HTTP ecosystem is prepared for things to "change later".

And therefore trailers still languish, 25 years after they were first proposed.

My suggestion is to finally break the deadlock by nixing the "change things later" aspect once an for all.

Yes, that leaves some slivers of optimization unrealized.

But would finally allow us to lay

	1.  "What if production goes wrong half way?"

and

	2.  "Why cant we (safely) produce and transmit concurrently?".

to bed.

-- 
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 10:42:31 UTC