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: Sun, 7 Jan 2024 10:33:25 -0800
I think what I proposed for GOAWAY has the same idea as
CURLOPT_PREREQFUNCTION.
What do you think?
On Sun, Jan 7, 2024 at 10:24 AM Cao Duc Quan <caoducquan_at_gmail.com> wrote:
> Sorry, seems I only replied to you in previous emails.
>
> Are you saying that you want to proactively drop the in-progress streams
>> as soon as a GOAWAY frame has been received?
>
> No, it's not. With the patch I proposed, on the callback of the
> GOAWAY frame, I did the following logic:
> - 1. Create a new CURLM object and make an HTTP GET to the server to open
> a new HTTP2 connection.
> - 2. Make the new CURLM object (created in 1) to new active transport and
> serve any new requests.
>
> The old CURLM object will be destroyed when the server closes the
> connection explicitly.
>
>
> On Sun, Jan 7, 2024 at 1:02 AM Ray Satiro via curl-library <
> curl-library_at_lists.haxx.se> wrote:
>
>> On 1/6/2024 12:04 PM, Cao Duc Quan wrote:
>> > "During" means the time since the Server sends the GOAWAY frame till
>> > the Server explicitly closes the TCP connection. This window is 60s.
>> > My library starts a new connection with an HTTP GET to the server and
>> > the server will respond in multipart. This HTTP request won't be
>> > finished until the server sends the last_boundary and END_FLAG in the
>> > stream which happens after sending the GOAWAY frame.
>> >
>> > I learned that when receiving a GOAWAY frame, cURL will mark the
>> > connection as closed and will send any new request on the new
>> > connection. However, the old connection has the in-progress stream
>> > active so it won't close the connection immediately when receiving the
>> > GOAWAY frame.
>> >
>> > What is the main reason for pushing back the change to support
>> > callback for the GOAWAY frame? I think we have multiple callbacks to
>> > allow the application to fine-tune the socket option ... which is also
>> > low-level in the protocol, why stop us from having a similar thing for
>> > HTTP2?
>>
>>
>> (The quoted text above was sent only to me, I assume by mistake, so I'm
>> replying to the mailing list)
>>
>> I still do not understand how it helps you to respond to the GOAWAY
>> frame. It sounds like curl is functioning as intended and new requests
>> are sent on a new connection. Are you saying that you want to
>> proactively drop the in-progress streams as soon as a GOAWAY frame has
>> been received?
>>
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>>
>
>
> --
> --------------------------------
> Watson Cao
> VN: (+84) 0976574864
> CA: (+1) 2368658864
>
Date: Sun, 7 Jan 2024 10:33:25 -0800
I think what I proposed for GOAWAY has the same idea as
CURLOPT_PREREQFUNCTION.
What do you think?
On Sun, Jan 7, 2024 at 10:24 AM Cao Duc Quan <caoducquan_at_gmail.com> wrote:
> Sorry, seems I only replied to you in previous emails.
>
> Are you saying that you want to proactively drop the in-progress streams
>> as soon as a GOAWAY frame has been received?
>
> No, it's not. With the patch I proposed, on the callback of the
> GOAWAY frame, I did the following logic:
> - 1. Create a new CURLM object and make an HTTP GET to the server to open
> a new HTTP2 connection.
> - 2. Make the new CURLM object (created in 1) to new active transport and
> serve any new requests.
>
> The old CURLM object will be destroyed when the server closes the
> connection explicitly.
>
>
> On Sun, Jan 7, 2024 at 1:02 AM Ray Satiro via curl-library <
> curl-library_at_lists.haxx.se> wrote:
>
>> On 1/6/2024 12:04 PM, Cao Duc Quan wrote:
>> > "During" means the time since the Server sends the GOAWAY frame till
>> > the Server explicitly closes the TCP connection. This window is 60s.
>> > My library starts a new connection with an HTTP GET to the server and
>> > the server will respond in multipart. This HTTP request won't be
>> > finished until the server sends the last_boundary and END_FLAG in the
>> > stream which happens after sending the GOAWAY frame.
>> >
>> > I learned that when receiving a GOAWAY frame, cURL will mark the
>> > connection as closed and will send any new request on the new
>> > connection. However, the old connection has the in-progress stream
>> > active so it won't close the connection immediately when receiving the
>> > GOAWAY frame.
>> >
>> > What is the main reason for pushing back the change to support
>> > callback for the GOAWAY frame? I think we have multiple callbacks to
>> > allow the application to fine-tune the socket option ... which is also
>> > low-level in the protocol, why stop us from having a similar thing for
>> > HTTP2?
>>
>>
>> (The quoted text above was sent only to me, I assume by mistake, so I'm
>> replying to the mailing list)
>>
>> I still do not understand how it helps you to respond to the GOAWAY
>> frame. It sounds like curl is functioning as intended and new requests
>> are sent on a new connection. Are you saying that you want to
>> proactively drop the in-progress streams as soon as a GOAWAY frame has
>> been received?
>>
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>>
>
>
> --
> --------------------------------
> Watson Cao
> VN: (+84) 0976574864
> CA: (+1) 2368658864
>
-- -------------------------------- 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-07