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: Cao Duc Quan via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 10 Jan 2024 22:13:51 -0800
If I grasp your point correctly, the statement "*curl may not process a
GOAWAY immediately*" implies that there might be a delay in some of cURL's
internal logic until a user initiates a request. However, I believe that my
proposal will ensure the callback is triggered promptly whenever nghttp2
receives a GOAWAY frame, as it will be invoked within the
nghttp2_session_callbacks_set_on_frame_recv_callback() chain, possibly
passing through the layers of socket -> ssl -> nghttp2.
On Wed, Jan 10, 2024 at 9:26 PM Ray Satiro via curl-library <
curl-library_at_lists.haxx.se> wrote:
> 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.html
>
Date: Wed, 10 Jan 2024 22:13:51 -0800
If I grasp your point correctly, the statement "*curl may not process a
GOAWAY immediately*" implies that there might be a delay in some of cURL's
internal logic until a user initiates a request. However, I believe that my
proposal will ensure the callback is triggered promptly whenever nghttp2
receives a GOAWAY frame, as it will be invoked within the
nghttp2_session_callbacks_set_on_frame_recv_callback() chain, possibly
passing through the layers of socket -> ssl -> nghttp2.
On Wed, Jan 10, 2024 at 9:26 PM Ray Satiro via curl-library <
curl-library_at_lists.haxx.se> wrote:
> 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.html
>
-- -------------------------------- Watson Cao VN: (+84) 0976574864 CA: (+1) 2368658864
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-11