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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 11 Jan 2024 14:42:30 +0100 (CET)
On Wed, 10 Jan 2024, Cao Duc Quan via curl-library wrote:
> 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
As Jay has explained, that might not happen depending on circumstances so you
would have to poll the server frequently or keep never-dying stream alive.
Reading this thread, it appears to me that you are trying to glue a rather
convoluted and fragile solution into libcurl because your server acts oddly on
you and you cannot control the server. It does not sit right with me.
It would make so much more sense if your server would simply *message* your
application that it is time to start a new connection and then you do that,
using existing mechanisms. You would have to have a communication going with
the server anyway to get the GOAWAY so why not just get it cleanly *as plain
data*? Since you need that poll setup anyway.
Optionally, your client just starts a new connection for every Nth request
before the server even tells you. Even simpler.
Date: Thu, 11 Jan 2024 14:42:30 +0100 (CET)
On Wed, 10 Jan 2024, Cao Duc Quan via curl-library wrote:
> 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
As Jay has explained, that might not happen depending on circumstances so you
would have to poll the server frequently or keep never-dying stream alive.
Reading this thread, it appears to me that you are trying to glue a rather
convoluted and fragile solution into libcurl because your server acts oddly on
you and you cannot control the server. It does not sit right with me.
It would make so much more sense if your server would simply *message* your
application that it is time to start a new connection and then you do that,
using existing mechanisms. You would have to have a communication going with
the server anyway to get the GOAWAY so why not just get it cleanly *as plain
data*? Since you need that poll setup anyway.
Optionally, your client just starts a new connection for every Nth request
before the server even tells you. Even simpler.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-11