-
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
x/net/http2: certain HTTP2 requests sends a "END_STREAM" prematurely #28206
Comments
It might be a dupe of #25009. When retrying a POST with http/2, the body was not reset on the new request. |
/cc @bradfitz |
Are you able to provide a sample code reproducing the issue? |
I wish I could. The problem is not deterministic, it happens sporadically. I am not even unable to recreate this locally on my developer Mac computer using the same code. I have only been able to debug this directly in production where we have deployed our app on GCP Kubernetes. I don't know why. |
Just a quick update regarding this issue; We've been doing tests by changing the client implementations, and we have noticed when using ..
|
@corgrath any news? :) Actually I think that we can close this. |
We are not running 1.12 in production yet, so I haven't been able to verify this with HTTP2, but sure, it can get closed. |
Closing then. Please feel free to reopen if you see this again with 1.12. Thanks |
Our organization is using a Go backend in order to send POST API requests to various HTTPS end points.
The example below is for a service called Iterable (api.iterable.com:443), but we see similar problems with others hosts, so we believe there is a problem with the Go HTTP2 stack, somehow. But we are unsure what to look at in order to understand what the causes our failed requests on our environment.
We have noticed that every once and a while, a request just breaks and we get back from Amazon Web Service a
400 BAD REQUEST
.In order to figure out why, I have enabled
GODEBUG=http2debug=2
and I am comparing a failed request against a succeeding requests.I see a pattern where a failing requests does a
END_STREAM
prematurely, before sending the data, while working requests sends its data, thenEND_STREAM
.However, we can send two requests after each other, same code, same payload and one succeeds and the other might fail.
We have not yet figured out why.
What version of Go are you using (
go version
)?1.11
Does this issue reproduce with the latest release?
N/A
What operating system and processor architecture are you using (
go env
)?What did you expect to see?
Having
GODEBUG=http2debug=2
enabled, I am trying to figure out why certain Go HTTP2 requests fail, while others succeed.The definition of a failed requests is that Amazon Web Services is sending a
400 BAD REQUEST
, while200
on others.Our code is static, the payload might change, but according to the dump, our payload is not event sent before AWS closes down the client.
A working request 1
A working request 2
A failing request
Comparison
When I compare the two dumps side by side, the only significant changes I see is that the
read SETTINGS len=18, settings: MAX_CONCURRENT_STREAMS=128, INITIAL_WINDOW_SIZE=65536, MAX_FRAME_SIZE=16777215
comes earlier in the working request, but later in the failing one.Another significant change is that on the failing requests, you can see:
But on the working, the data is actually sent before
END_STREAM
;Working request 1:
Working request 2:
But I don't know why.
My questions
I am not familiar with these dumps and how to read them, but I have two questions:
Is there anything in the dumps that can explain why Go HTTP2 sends a premature
END_STREAM
on certain requests, but manages to send the payload on the others?We are using
http.NewRequest(method, url string, body io.Reader)
which hasif req.GetBody != nil && req.ContentLength == 0 {
so, if we were indeed sending empty data (which Ive tripled checked), this would have stopped it right (?). Is there anythingGODEBUG=http2debug=2
that can testify there is a payload in the POST request?Any feedback would be appreciated!
The text was updated successfully, but these errors were encountered: