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 <caoducq...@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.html
