Re: Cache control in trailers?

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