Re: Cache control in trailers?

--------
Adrien de Croy writes:

> at the cost of the ability to block on any metadata without having to=20
> spool the entire resource (and delay it).

Uhm, we must be talking waaaaay past each other here...

The scenario where trailes offer low hanging fruit is:

	client:			server:
	-------------------------------------------------------
	request -->

				start production of dynamic response body
				since we cannot know what it will be, we
				have to spool it locally first.
				chew
				chew
				chew	
				chew	
				AhA!  Now we are certain what metadata properties
				the response should have
				produce headers
				send headers
				send body
	receive headers
	chugga
	chugga
	chugga
	chugga
	chugga
	finish receiving body
			

Today nobody supports trailers, so the server is forced to spool
the body locally, so the transmission can only start once the
entire, possibly very large body has been produced.

With my proposal:

	client:			server:
	-------------------------------------------------------
	request -->

				Hmm, we need trailers
				send new 3xx code, saying metadata comes last
	receive 3xx
				start production of dynamic response body
				send stuff as soon as it is produced
				chew
	receive body		chew
				chew	
	receive more body	chew	
				send final chunk
				AhA!  Now we know what metadata properties the response should have
	receive end of body
				produce headers
				send headers
	receive headers
	act on headers & body

In short, the spooling is moved from the server to the client,
which means the transmission of it overlaps the production,
and the server gets to determine the metadata as production
progresses.

-- 
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 Thursday, 4 February 2021 23:52:58 UTC