Re: Cache control in trailers?

--------
Mark Nottingham writes:

> One of the fundamental limitations of HTTP that people often bump into 
> is that the status code and headers precede the body,[1] so if something 
> goes wrong while the response is being generated, they can get into 
> awkward situations.

...and having an ambiguity between headers and trailers will make for even more awkward situations.

As far as I can tell, allowing trailers to change anything fundamental about the object just shifts the need to buffer the entire object to the next step in the food-chain.

But that can still be a significant improvement, because production and transmission overlaps.

If we want enable that, we should move *all* headers and status to the trailer, so that no confusion is possible.

The way to do that is to define a new 1xx status code, which says the body comes first and should not be touched until trailers tell what it is.

Since there is no credible use-case where the content-length is already known, for HTTP/1.1 chunked encoding can be implied by the 1xx code.

So it could look something like this:

	HTTP/1.1 142 Wait For Trailers<CRNL>
	<CRNL>
	<chunked length><CRNL>
	chunk<CRNL>
	[...]
	<chunked length><CRNL>
	chunk<CRNL>
	0<CRNL>
	HTTP/1.1 200 OK<CRNL>
	Content-Length: 34242<CRNL>
	Cache-Control: blabla<CRNL>
	[...]
	<CRNL>

If we want to make it more robust against misimplementions we move the status line last:

	HTTP/1.1 142 Wait For Trailers<CRNL>
	<CRNL>
	<chunked length><CRNL>
	chunk<CRNL>
	[...]
	<chunked length><CRNL>
	chunk<CRNL>
	0<CRNL>
	Content-Length: 34242<CRNL>
	Cache-Control: blabla<CRNL>
	[...]
	HTTP/1.1 200 OK<CRNL>
	<CRNL>

Finally, we should give senders a way to prevent or at least seriously discourage receivers for peeking until the trailers have arrived: Let the sender XOR the body with a random number, to be disclosed in a trailer-only field.

The final bit is for requestors to indicate that they grok 142, I would be willing to abuse Accept-Encoding for that:

	Accept-Encoding: gzip, brotli, 142

-- 
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 08:22:52 UTC