-
Notifications
You must be signed in to change notification settings - Fork 17.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
net/http: GOAWAY reported as http.http2GoAwayError instead of http2.GoAwayError #28930
Comments
I think you mean to say that |
@agnivade Not sure exactly what should be the solution, but there should be a way to "catch" this error. Btw, the posiibility to return package-specific error to other packages seems somewhat wrong. |
Oh my bad, I thought you wanted to expose the error. The original issue title was correct then. |
This is an unfortunate side effect of how we bundle http2 into net/http. There really are two distinct types, copies of each other: http.GoAwayError and net/http.http2GoAwayError. We're not going to export the latter. But this isn't even an error that's meant to be acted on: the server sends those during graceful shutdown but shouldn't be interrupting existing requests in flight. If the GOAWAY last_stream_id is less than the one we just sent, the Transport will already reschedule it onto a different/new connection. The only time you should be seeing this if the response body was already partially sent/consumed and the server just closed the connection un-gracefully. But that's no more interesting than a server that just had its http server crash or otherwise closed its TCP connections ungracefully. If it's important to you, retry. Why is this specific error interesting? If it is, we could add an Could you explain more about why you care about this error in particular? |
That's probably my case. I send multiple requests to low performance server at one time (scrapper). It seems that when nginx feels overloaded it just sends goaway in the middle of response - which effectively means that I get no useful response. But this is really not important - tha case is that sometimes TCP connection returns error instead of useful response - developer should have opportunity to handle it I suppose. I should retry you say, and it is precisely what I do. But when should I retry? I react to So in effect, I can react to this specific error either via
In conclusion - I do not want to react precisely to |
Or |
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Get an URL, and try to read the body:
The server occasionaly closes the connection with GOAWAY, probably when overloaded with requests - the sample app scrapes many urls in short period of time.
What did you expect to see?
Error that could be caught by the code and potentially handled (retry GET):
The
http2.GoAwayError
struct I found on the github in other issues.What did you see instead?
Error was not recognized by above assert, instead it was passed to general error handler. Reflection on the error gave this data:
It seams that error is of type
http.http2GoAwayError
which is internal package's struct and cannot be used in my code.My HTTPS server (nginx) upgrades connections from HTTP to HTTP/2, so maybe the issue is when connection from http.Get is upgraded under the hood to HTTP/2 and the code does not translate the error codes appropriately?
Btw. Error reporting is not the best go's feature - it is hard to know what types of error can be returned to handle them accordingly. And the docs do not always tell everything either. The GOAWAY error I got from testing, though I wrote error handling.
The text was updated successfully, but these errors were encountered: