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: Fri, 12 Jan 2024 08:43:02 -0800
>
> 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.
>
Thank you, Daniel, for your insightful suggestions. While I acknowledge
that it's a viable option, it appears to introduce redundancy by
duplicating information at the application layer for the transmission of
plain data. Given that both the client and server utilize HTTP2, wouldn't
it be more efficient to leverage the GOAWAY frame instead?
On Thu, Jan 11, 2024 at 5:42 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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
>
Date: Fri, 12 Jan 2024 08:43:02 -0800
>
> 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.
>
Thank you, Daniel, for your insightful suggestions. While I acknowledge
that it's a viable option, it appears to introduce redundancy by
duplicating information at the application layer for the transmission of
plain data. Given that both the client and server utilize HTTP2, wouldn't
it be more efficient to leverage the GOAWAY frame instead?
On Thu, Jan 11, 2024 at 5:42 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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
>
-- -------------------------------- 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-12