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: Sun, 7 Jan 2024 18:00:38 -0500
On 1/7/2024 1:33 PM, Cao Duc Quan wrote:
> I think what I proposed for GOAWAY has the same idea as
> CURLOPT_PREREQFUNCTION.
> What do you think?
>
> On Sun, Jan 7, 2024 at 10:24 AM Cao Duc Quan <caoducquan_at_gmail.com> wrote:
>
> Sorry, seems I only replied to you in previous emails.
>
> Are you saying that you want to proactively drop the
> in-progress streams as soon as a GOAWAY frame has been received?
>
> No, it's not. With the patch I proposed, on the callback of the
> GOAWAY frame, I did the following logic:
> - 1. Create a new CURLM object and make an HTTP GET to the server
> to open a new HTTP2 connection.
> - 2. Make the new CURLM object (created in 1) to new active
> transport and serve any new requests.
>
> The old CURLM object will be destroyed when the server closes the
> connection explicitly.
>
Please do not top-post it makes the conversation hard to follow. [1]
You are asking for a low level signal that almost nobody needs. It
sounds like you are trying to work around a server or application issue.
Why would you create a new multi? What is the disadvantage of keeping
the requests in the original multi? If curl is working properly then as
we discussed it opens a new connection for the subsequent requests. Are
you using the latest curl?
[1]: https://curl.se/mail/etiquette.html#Do_Not_Top_Post
Date: Sun, 7 Jan 2024 18:00:38 -0500
On 1/7/2024 1:33 PM, Cao Duc Quan wrote:
> I think what I proposed for GOAWAY has the same idea as
> CURLOPT_PREREQFUNCTION.
> What do you think?
>
> On Sun, Jan 7, 2024 at 10:24 AM Cao Duc Quan <caoducquan_at_gmail.com> wrote:
>
> Sorry, seems I only replied to you in previous emails.
>
> Are you saying that you want to proactively drop the
> in-progress streams as soon as a GOAWAY frame has been received?
>
> No, it's not. With the patch I proposed, on the callback of the
> GOAWAY frame, I did the following logic:
> - 1. Create a new CURLM object and make an HTTP GET to the server
> to open a new HTTP2 connection.
> - 2. Make the new CURLM object (created in 1) to new active
> transport and serve any new requests.
>
> The old CURLM object will be destroyed when the server closes the
> connection explicitly.
>
Please do not top-post it makes the conversation hard to follow. [1]
You are asking for a low level signal that almost nobody needs. It
sounds like you are trying to work around a server or application issue.
Why would you create a new multi? What is the disadvantage of keeping
the requests in the original multi? If curl is working properly then as
we discussed it opens a new connection for the subsequent requests. Are
you using the latest curl?
[1]: https://curl.se/mail/etiquette.html#Do_Not_Top_Post
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-08