Re: Cache control in trailers?

Hi,

One other thought is that if there was an error then the last 10 bytes of
the stream will signal it,
Which would be a signed payload, as not confuse with normal body content,
the signing could be sent in the headers,
which basically say from this position back 300bytes for trailing headers
or that it is all good.
This would be simpler and upon encapsulating control protocol signally the
end of transmission, the last 10 bytes of the response
would always need to be checked as to ascertain if HTTP was success or
failure. That way no modifications would be
required to the encapsulating control protocol.
The only thing, similar to file upload, I do worry about is an error
occurring perfectly on the founder of the response body, but if
always has to be present for successful response and failure response it
shouldn't be a problem. However, without an HTTP protocol
flag support specifying this mode, it can't be implicit, because if
implicitly, the backwards compatibility with implicit support,
would suffer from the chance that the last part of the body, by chance
matches the signature ad last 10bytes indicate success or failure.

This mode of transmission for the protocol definitely will be required to
avoid this, and expectation of support to be communicated upfront in the
first headers or protocol version indicate support for
there always being a signed 10bytes of success or failure indicator.

Kind Regards,

Wesley Oliver


On Mon, Feb 8, 2021 at 11:37 AM Wesley Oliver <wesley.olis@gmail.com> wrote:

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


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