Re: Cache control in trailers?

Hi,

The one obvious thing missing is you are relaying of the buffer size being
smaller, then
basically, there will be padding to cause a next smaller buffer at a
certain point.
In this case, one is going to need the content-length header to be
transmitted as well in the trailing-headers
because one will need to be able to strip away the padding that used to
create the end buffer trigger.
There is another additional header that is required.

Kind Regards,

Wesley OLiver

On Tue, Feb 9, 2021 at 9:02 AM Wesley Oliver <wesley.olis@gmail.com> wrote:

> Hi,
>
> Basically, I would agree with you here.
>
> The issues about the encapsulation protocol, requiring to be able to
> communicate like a buffer end of section transmission end by indicating the
> bytes sent,
> such that the recipient can then inspect the last bit of information
> received and jump back to the offset of the trailing headers if
> encapsulating protocol is not able to
> reliably signal such an event, or can only signal the end of a section
> possibly, where there can be false negatives, without the final offset.
> Then basically the 8 bytes of end data signalling offset and success that
> must always be there in this mode would need to support an escaping scheme,
> such that the last select of received data can be scanned, for the ending
> of transmission, because you won't know the length of data upfront and even
> if you do on error,
> it won't have transmitted all that data, so you would have to send padding
> and wasted bandwidth.
>
> Obviously, this has an impact for speed, so ideally on wants some form of
> the control signal to be able to trigger the scanning opposed to scanning
> everything.
> If one is able to rely on a specific buffer size of transmission always
> being full, then only need to check on the server and the client that the
> last buffer that is not expected to be full,
> before transmission and after receiving, which give you the chances to
> escape content, before transmission, however, you don't want to double
> buffer the transmission, you preferable
> like to directly update the buffer written to for transmission. The same
> would happen on the client-side upon receiving a non-full buffer.
> If a buffer where to perfectly end on the buffer size, then is bit of a
> problem, so upon final dynamic generation or content generation, one would
> need to write and explicit
> check-in, that if the buffer size match that, need to escape and
> transmitted another buffer of content, to trigger the client-side checking.
> Relying on partially full last buffer size check would reduce the need for
> the encapsulating protocol, signal.
>
> Ability to have buffer size that naturally allows alignment would reduce
> scanning overhead, however, using triggering on buffer not be full, would
> eliminate the need for
> escaping, because just made this constraint condition existing, which when
> violated, no need to check for last trailing 8 bytes giving the offset
> backwards.
>
> The other thing that would be nice is that one can override the HTTP
> status and cache status, however, still follow up with an additional
> redirect, location header, so only error there is automatically redirected
> to and error page as well.
>
> I think that a new name for AcceptTrailers CacheControl would be needed
> and changed to something like
> NonBufferResponse, which would be equivalent to CacheControl | Status |
> Location, as a location now has a temporary redirect
> implied status, when used with CacheControl.
>
> Kind Regards,
>
> Wesley Oliver
>
> On Mon, Feb 8, 2021 at 5:06 PM Greg Wilkins <gregw@webtide.com> wrote:
>
>>
>>
>> On Mon, 8 Feb 2021 at 13:44, Willy Tarreau <w@1wt.eu> wrote:
>>
>>> Maybe we need to implement something between TE and Trailers so that
>>> the client could suggest the server to place certain fields in the
>>> trailer part.
>>>
>>
>> I think this is the crux of the matter. Servers can already put pretty
>> arbitrary fields into trailers if the client says
>>   TE: trailers
>>
>> But that is too coarse a switch, because the server cannot know which
>> particular fields the client is able to handle in the trailers.  It may be
>> expecting only a check-sum or similar in the trailer, so if the server
>> starts sending Cache-Control and/or End-Status fields, then it has no
>> way to know if the client will actually interpret them.
>>
>> Perhaps we need to send requests something like
>>
>>   Accept-Trailer: Cache-Control
>>   TE: trailers
>>   Connection: TE, Accept-Trailer
>>
>> If an intermediary is happy to buffer the entire content before acting,
>> then it can send requests like:
>>
>>   Accept-Trailer: *
>>   TE: trailers
>>   Connection: TE, Accept-Trailer
>>
>> Servers that send trailer fields that are not listed in an Accept-Trailer
>> should only consider them advisory and cannot assume that the client will
>> actually interpret them... which is kind of the state today anyway.
>>
>> cheers
>>
>>
>>
>>
>> --
>> Greg Wilkins <gregw@webtide.com> CTO http://webtide.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