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 16:47:41 -0800
>
> 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?
On Sun, Jan 7, 2024 at 3:00 PM Ray Satiro via curl-library <
curl-library_at_lists.haxx.se> wrote:
> On 1/7/2024 1:33 PM, Cao Duc Quan wrote:
>
> 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.
>>
>
> Please do not top-post it makes the conversation hard to follow. [1]
>
> 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. Why would
> you create a new multi? What is the disadvantage of keeping the requests in
> the original multi? If curl is working properly then as we discussed it
> opens a new connection for the subsequent requests. Are you using the
> latest curl?
>
>
> [1]: https://curl.se/mail/etiquette.html#Do_Not_Top_Post
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>
Date: Sun, 7 Jan 2024 16:47:41 -0800
>
> 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?
On Sun, Jan 7, 2024 at 3:00 PM Ray Satiro via curl-library <
curl-library_at_lists.haxx.se> wrote:
> On 1/7/2024 1:33 PM, Cao Duc Quan wrote:
>
> 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.
>>
>
> Please do not top-post it makes the conversation hard to follow. [1]
>
> 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. Why would
> you create a new multi? What is the disadvantage of keeping the requests in
> the original multi? If curl is working properly then as we discussed it
> opens a new connection for the subsequent requests. Are you using the
> latest curl?
>
>
> [1]: https://curl.se/mail/etiquette.html#Do_Not_Top_Post
>
> --
> 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.htmlReceived on 2024-01-08