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: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 7 Jan 2024 04:02:30 -0500
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?
Date: Sun, 7 Jan 2024 04:02:30 -0500
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.htmlReceived on 2024-01-07