curl / Mailing Lists / curl-library / Single Mail
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

From: Cao Duc Quan via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 10 Jan 2024 11:28:10 -0800

Hi Ray,

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


Sounds like we have agreement on the benefit of having this callback.

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.


I may have misunderstood, but there does not seem to be anything preventing
cURL from handling the GOAWAY frame in this case. My proposal is to add a
callback that signals the application when a GOAWAY frame is received (cURL
still handles GOAWAY frame as-is). This may be a chicken-and-egg situation
since we don't currently have such a callback in cURL, so the benefits are
not yet clear. However, I believe that supporting this could be helpful for
some use cases, including my own and the one described in issue #4839 that
you previously referenced. If cURL implemented a GOAWAY callback,
developers could respond appropriately on receipt of a GOAWAY, enabling
graceful shutdown of HTTP/2 connections in their applications.

Thanks,

On Tue, Jan 9, 2024 at 11:40 AM Ray Satiro via curl-library <
curl-library_at_lists.haxx.se> wrote:

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


-- 
--------------------------------
Watson Cao
VN: (+84) 0976574864
CA: (+1) 2368658864


-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2024-01-10