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:24:08 -0800
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
>
Date: Sun, 7 Jan 2024 10:24:08 -0800
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
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-07