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