-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Close the http2 connection when no more requests may be sent. #5643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Well-behaving HTTP2 servers send two GOAWAY messages. The first message is a warning that indicates that the server is going to stop accepting streams. The second one actually closes the stream. nghttp2 reports this state (and the other state of no more stream identifiers) via the call nghttp2_session_check_request_allowed(). In this state the client should not create more streams on the session (tcp connection), and in curl this means that the server has requested that the connection is closed. It would be also be possible to put the connclose() call into the on_http2_frame_recv() function that triggers on the GOAWAY message. This fixes a bug seen when the client sees the following sequence of frames: // advisory GOAWAY HTTP2 GOAWAY [stream-id = 0, promised-stream-id = -1] ... some additional frames // final GOAWAY HTTP2 GOAWAY [stream-id = 0, promised-stream-id = N ] Before this change, curl will attempt to reuse the connection even after the last stream, will encounter this error: * Found bundle for host localhost: 0x5595f0a694e0 [can multiplex] * Re-using existing connection! (#0) with host localhost * Connected to localhost (::1) port 10443 (#0) * Using Stream ID: 9 (easy handle 0x5595f0a72e30) > GET /index.html?5 HTTP/2 > Host: localhost:10443 > user-agent: curl/7.68.0 > accept: */* > * stopped the pause stream! * Connection #0 to host localhost left intact curl: (16) Error in the HTTP2 framing layer This error may posion the connection cache, causing future requests which resolve to the same curl connection to go through the same error path.
I believe this fixes the error mentioned here: We have manually worked around this error in tensorstore: https://github.com/google/tensorstore/blob/master/tensorstore/internal/http/curl_transport.cc#L274 I have reproduced the error with a GFE and verified that the fix no longer triggers the error when communicating with the same GFE. |
Thanks! |
ping @laramiel. This causes a fuzzer crash. I wonder if this isn't an nghttp2 bug...
|
The fuzzer currently runs with nghttp2 1.33.0. @tatsuhiro-t, do you happen to know if this is a known older bug in nghttp2 we've run into? |
We get the same crash even with nghttp2 1.41.0 (I updated the fuzzer):
|
Created a new separate issue for this in #5646 to make it more visible. |
It was found that the google storage api would cause curl to return a CURLE_HTTP2 error after around an hour. The workaround implemented here is to close the connection and open a new one. The issue appears similar to curl/curl#5389 and curl/curl#5643. The fix curl/curl@ef86daf didn't solve the issue (version 7.74.0).
It was found that the google storage api would cause curl to return a CURLE_HTTP2 error after around an hour. The workaround implemented here is to close the connection and open a new one. The issue appears similar to curl/curl#5389 and curl/curl#5643. The fix curl/curl@ef86daf didn't solve the issue (version 7.74.0).
Well-behaving HTTP2 servers send two GOAWAY messages. The first
message is a warning that indicates that the server is going to
stop accepting streams. The second one actually closes the stream.
nghttp2 reports this state (and the other state of no more stream
identifiers) via the call nghttp2_session_check_request_allowed().
When in this state the client should not create more streams on the
session (tcp connection), and in curl this means that the server
has requested that the connection is closed.
It would be also be possible to put the connclose() call into the
on_http2_frame_recv() function that triggers on the GOAWAY message.
This fixes a bug seen when the client sees the following sequence of
frames:
Before this change, curl will attempt to reuse the connection even
after the last stream, will encounter this error:
This error may posion the connection cache, causing future requests
which resolve to the same curl connection to go through the same error
path.