Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Support HTTP2 Goaway Frame callback for curl multi
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 11 Jan 2024 00:26:42 -0500
On 1/10/2024 2:28 PM, Cao Duc Quan wrote:
>
> Generally I agree that to lessen response times it is a good idea
> to have a valid established connection ready before subsequent
> requests are made to the same server
>
>
> Sounds like we have agreement on the benefit of having this callback.
>
> However I think the option you are proposing is too niche and
> there would not be a benefit for many users so I don't see the
> point in adding it. It does not necessarily work well because as
> discussed curl must process the GOAWAY and that is not guaranteed
> to happen immediately.
>
>
> I may have misunderstood, but there does not seem to be anything
> preventing cURL from handling the GOAWAY frame in this case. My
> proposal is to add a callback that signals the application when a
> GOAWAY frame is received (cURL still handles GOAWAY frame as-is). This
> may be a chicken-and-egg situation since we don't currently have such
> a callback in cURL, so the benefits are not yet clear. However, I
> believe that supporting this could be helpful for some use cases,
> including my own and the one described in issue #4839 that you
> previously referenced. If cURL implemented a GOAWAY callback,
> developers could respond appropriately on receipt of a GOAWAY,
> enabling graceful shutdown of HTTP/2 connections in their applications.
We do not have agreement on the callback. I agree that less latency is
better and I disagree with your solution for the reasons I already said.
The callback works for you because of the way you are using curl but, as
I already explained, in other cases curl may not process a GOAWAY
immediately.
Date: Thu, 11 Jan 2024 00:26:42 -0500
On 1/10/2024 2:28 PM, Cao Duc Quan wrote:
>
> Generally I agree that to lessen response times it is a good idea
> to have a valid established connection ready before subsequent
> requests are made to the same server
>
>
> Sounds like we have agreement on the benefit of having this callback.
>
> However I think the option you are proposing is too niche and
> there would not be a benefit for many users so I don't see the
> point in adding it. It does not necessarily work well because as
> discussed curl must process the GOAWAY and that is not guaranteed
> to happen immediately.
>
>
> I may have misunderstood, but there does not seem to be anything
> preventing cURL from handling the GOAWAY frame in this case. My
> proposal is to add a callback that signals the application when a
> GOAWAY frame is received (cURL still handles GOAWAY frame as-is). This
> may be a chicken-and-egg situation since we don't currently have such
> a callback in cURL, so the benefits are not yet clear. However, I
> believe that supporting this could be helpful for some use cases,
> including my own and the one described in issue #4839 that you
> previously referenced. If cURL implemented a GOAWAY callback,
> developers could respond appropriately on receipt of a GOAWAY,
> enabling graceful shutdown of HTTP/2 connections in their applications.
We do not have agreement on the callback. I agree that less latency is
better and I disagree with your solution for the reasons I already said.
The callback works for you because of the way you are using curl but, as
I already explained, in other cases curl may not process a GOAWAY
immediately.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-11