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: Tue, 9 Jan 2024 14:40:04 -0500
On 1/7/2024 7:47 PM, Cao Duc Quan wrote:
>
> 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.
>
> Agree my use case is quite odd but that is the protocol we developed
> for years and I saw the benefit of having this low-level signal. Is
> there any down-side to support this?
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. 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.
curl could use improvement in connection upkeep, see the TODO. [1] There
is only curl_easy_upkeep [2] which will send HTTP/2 PING, but currently
it is only for easy handles that are not part of a multi (eg easy
interface was used curl_easy_perform and not curl_multi_perform) and do
not have a shared connection cache. I think it may be possible to change
it to covered shared connection caches, I will check.
[1]: https://curl.se/docs/todo.html#Monitor_connections_in_the_conne
[2]: https://curl.se/libcurl/c/curl_easy_upkeep.html
Date: Tue, 9 Jan 2024 14:40:04 -0500
On 1/7/2024 7:47 PM, Cao Duc Quan wrote:
>
> 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.
>
> Agree my use case is quite odd but that is the protocol we developed
> for years and I saw the benefit of having this low-level signal. Is
> there any down-side to support this?
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. 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.
curl could use improvement in connection upkeep, see the TODO. [1] There
is only curl_easy_upkeep [2] which will send HTTP/2 PING, but currently
it is only for easy handles that are not part of a multi (eg easy
interface was used curl_easy_perform and not curl_multi_perform) and do
not have a shared connection cache. I think it may be possible to change
it to covered shared connection caches, I will check.
[1]: https://curl.se/docs/todo.html#Monitor_connections_in_the_conne
[2]: https://curl.se/libcurl/c/curl_easy_upkeep.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-09