-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
HTTP/2 request doesn't report the correct reason why request ends on connection GOAWAY #97128
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDescriptionIf a HTTP/2 request is being read from the response stream and the underlying HTTP/2 connection is killed because of a GOAWAY form the server, the user sees a deceptive message:
It gives the impression that the request ended because the server unexpectedly stopped sending response data. The real reason the response ended and there are no more frames is because the server closed the connection with a GOAWAY. That information (GOAWAY + enhance your calm protocol code) should be bubbled up to this error message. Something like:
Today the only way to figure out why the HTTP/2 request failed is to attach an event source listener. That displays:
Setting up an event source listener is advanced and shouldn't be required to find out important error information like this. Reproduction Steps
Here is an example in logs: Expected behaviorA more useful error message. It should say the response ended because the connection ended. It should include the GOAWAY error code. Something like:
Actual behaviorUnhelpful error message. Regression?No response Known WorkaroundsNo response ConfigurationNo response Other informationNo response
|
This should be a |
Description
A customer ran into a HTTP/2 error scenario and asked why the real failure reason wasn't in the error message: grpc/grpc-dotnet#2361 (comment). Seeing this error is important for debugging because the server can trigger a GOAWAY and knowing the error code is important for understanding why the server closed the connection.
Scenario:
The error gives the impression that the request ended because the server unexpectedly stopped sending response data. The real reason there are no more frames is because the server closed the connection with a GOAWAY. That information (GOAWAY + enhance your calm protocol code) should be bubbled up to this error message.
Something like:
Today the only way to figure out why the HTTP/2 request failed is to attach an event source listener. That displays:
Setting up an event source listener is advanced and shouldn't be required to find out important error information like this.
Reproduction Steps
Here is an example in logs:
ping-goaway.txt
Expected behavior
A more useful error message. It should say the response ended because the connection ended. It should include the GOAWAY error code.
Something like:
Actual behavior
Unhelpful error message.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: