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 <caoducq...@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@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.html
