Re: Cache control in trailers?

Hi,

The thing is that on error, that need to signal a communications protocol
error, signify the data position of the body that has been transmitted, so
it can figure out
where the trailing headers will be, versus the trailing headers being
actually being transmitted in the chuck encoding. In m mind one requires an
external
communication mechanism, to break the expected data to be received, in
which trailing headers, would be misinterpreted as the body of the response.

Kind Regards,

Wesley Oliver

On Sat, Feb 6, 2021 at 4:48 PM Wesley Oliver <wesley.olis@gmail.com> wrote:

> Hi,
>
> I typically agree with rather moving to max-age. I recently had some great
> fun with authentication, where mobile phones local time could be out
> and so can the server, extra. that basically I typically came up with the
> idea, when generating expire for like jwt, that one wants to encode the
> local client device time and server time in there
> and work to the one,which is gong to make things work the best, when
> evaluating expire, wanting to refresh a jwt before it expires, using local
> device time, as may not be insync with the server.
> Then again also just just invalidate all signature on deployment, forcing
> all jwt to become invalid and fail authentication.
>
> I would be for both a status code and for the ability to override the
> Cache-Control header in trailing headers, or something similar.
> Obviously one would need the request to specify its support for these
> features, either protocol version or optional request support headers,
> So that on clients that don't support the behaviour, the old approach can
> still be taking of buffering everything.
>
> The semantics of page erroring, one client immediately tries again, in
> which the default behaviour of must-revalidate,
>  in subsequent request on may want to change that to reduce the load
> caused by the internal server error, however, this would
> require that one could count the client requests, which becomes complex,
> if this is not like a statless jwt put in request forward headers, which
> don't exist yet,
> so one would need to use a cookie, not idea, as that for bowser really.
> Upon reaching a certain count, would could put out a different expire time
> of 5 minutes, however, right now the logic for system behind load balance,
> could become quite complex to implement.
>
> If one is able to easily monitor URL errors and dynamically change the
> cache-control header, one would be able to reduce load continuously being
> created by this error,
> However, it may be simpler that for certain classes of HTTP status codes,
> on set maybe different Cache-Control overides, but starting with since one
> for one is great, see how we go.
> as setting it to 5 minutes, would reduce massive amounts of load, to
> generate the content on the server, however, fail at some point when
> sending it to the client with (I hate autocorrect now aws=was)
> AWS your are basically paying for this, so maybe one adds in a circuit
> breaker here to any upstream, with the 5 minutes that would allow it to
> break the load on the upstreams.
> but one has to wrap to manage list of all forward requests.
>
> it could be the case, where typically I don't have a lot of load, from
> this functionality, so its working fine, however, if were to fail
> the serverside overhead and waisted cpu cycle and
> partial bandwidth would be terrible. In this case one could possible
> recommend, that if a server failed with trailing headers, that it should
> revert for the next URL unique request to buffering if possible,
> to reduce the bandwidth consumption to the client, by first ensuring it
> could generate a response with no errors, there after it could resume
> normal streaming mode or proxy could convert the request,
> if response headers allowed for it.
> But allowing one to override the default Cache-Control would be great to
> prevent this from happening to a degree.
>
> One thing new feature that would be possible is if the downstream are
> allow to change the response to streaming response with trailing headers,
> one would need to indicate
> in a response header if that are allowed to do this, as may just be a
> blanket setting turn on for the outside facing world, which the result in a
> behaviour that is not desirable
> for the consumer of the response for rendering extra.
>
> Maybe one may want a backoff period instead, which can be overridden by
> forced refresh request, the backoff would just reduce load attract on the
> system, by my hitting try again,
> successively and abusively, give overloading the servers, with failed
> requests, however, stream trailing headers, would mean I would be paying a
> bandwidth penalty.
>
> Kind Regards,
>
> Wesley Oliver
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_-7276197523490670123_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sat, Feb 6, 2021 at 11:43 AM Willy Tarreau <w@1wt.eu> wrote:
>
>> On Sat, Feb 06, 2021 at 10:31:42AM +0100, Greg Wilkins wrote:
>> > Sorry, I'm definitely guilty of getting distracted by the conversation
>> and
>> > forgetting aspects of the trailer mechanism...
>> >
>> > Going back to Mark's original post.   He had two proposals: "indicate
>> the
>> > error in trailers"; "to allow Cache-Control: no-cache in trailers".
>> >
>> > For the first proposal, I'll repeat my initial feedback: it is a bad
>> idea
>> > to handle errors during generation by correctly terminating a 200
>> response
>> > in order to put an error status into the trailers.
>> > Clients/intermediaries that don't support the specific error/status
>> field
>> > would see this as a valid response.  Specifically I think it is a bad
>> idea
>> > to do:
>> >     HTTP/1/1 200 OK
>> >     Trailer: end-status
>> >     ... body...
>> >     End-Status: 500
>> >
>> > I can only see this as being workable in a 200 response if there is a
>> > really reliable way for the client and all intermediaries to indicate
>> their
>> > support of End-Status specifically and not just support for Trailers
>> > generally.
>>
>> Agreed. In general I'm not against the use of a status, but we currently
>> don't have statuses that mean "suboptimal response, please don't rely too
>> much on it". Conversely, cache-control semantics allow to send a short
>> "max-age" and a "must-revalidate", to warn the client about possibly poor
>> content quality while letting the server recover from the bad condition.
>>
>> This is why I'd prefer a trailer field completing cache-control, but I'd
>> be fine with just a status if we define one meaning just this.
>>
>> Willy
>>
>>
>
> --
> ----
> 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