Re: Cache control in trailers?

Hi,

So basically something along the lines of the following will need to be
sent to prevent same issues as file upload chance of happening.
if you were using quick, say when doing a special stream buffer flush,
those protocols upon which HTTP can't provide this end frame of transmitted
bytes up until such a point will possibly have the chance of suffering same
issues as file upload, or some part of the trailing body
gets recognised as final 10 bytes.
RST frame with final byte offset
Data frame with FIN bit set

Kind Regards,

Wesley Oliver

On Mon, Feb 8, 2021 at 12:05 PM Wesley Oliver <wesley.olis@gmail.com> wrote:

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


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