Re: Cache control in trailers?

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

Of the listed examples, only "framing" cannot wait[1], the rest of
the examples provided are simply wrong:  None of that information
is in any way required to receive and temporarily spool the body[2].

I dont know when or why this assumption was made silent canon in
the HTTP protocol, but I will argue that it is:

A) Bad Architecture.

B) A really big roadblock for trailers.

C) Preventing us from reaping obvious and significant speed benefits.

D) Not documented anywhere.

If, after discussion, consensus is that there are good reasons for
keeping this assumption, we should document that, if there are not,
we should get rid of it.

Poul-Henning

[1] And one could reasonably ask what is that even doing in the
semantics in the first place ?  Yes, *I* know, you dont need to
explain it, but if you came to this fresh, you would wonder.

[2] That is not to say that the headers cannot provide useful
hints such as "expect around 3 megabytes" or "you'll need a
sha256 digest later", but they are just hints.

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