Re: Cache control in trailers?

  Hi,

But that is why send those headers upfront  if they not sent it would a be
a communication protocol error for HTTP as they had be sent upfront and
then along send
possible headers in this case and some other that would logically be
allowed to be sent as trailing headers and some which have overriding
behaviour.

External communications control protocol upon which HTTP runs, would need
to support a signal that there was and error and that at certain byte offset
the assume override or trailing headers in the transmission could be found.
Otherwise, the response would need to be padded, to meet the mini
communicated blocks transmissions size,
leading to a lot of more waisted bandwidth.As you can't predict and error.

Kind Regards,

Wesley Oliver



On Mon, Feb 8, 2021 at 10:54 AM Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

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

-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.olis@gmail.com