-
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: TestServer_RejectsLargeFrames fails with "An existing connection was forcibly closed by the remote host" on windows #13434
Comments
The client sends too much data. The server replies with a Write of GOAWAY + also closes the TCP connection. The client tries to read, and sees "wsarecv: An existing connection was forcibly closed by the remote host" before the GOAWAY. |
I suspect you are correct. But why you can read last GOAWAY message on unix, but not on Windows? In fact I can make the test PASS on windows, if I adjust some timers in your code. Strange. Alex |
I could reproduce this.
|
diff --git a/http2/frame.go b/http2/frame.go
index 6b8a74f..0ef0f6c 100644
--- a/http2/frame.go
+++ b/http2/frame.go
@@ -133,6 +133,7 @@ var frameParsers = map[FrameType]frameParser{
}
func typeFrameParser(t FrameType) frameParser {
+ println("frame type is", t)
if f := frameParsers[t]; f != nil {
return f
} When modify frame.go like above.
Some FrameSettings comes. After many FrameData comes. |
I had some time to play with this. I made this changes:
so I can log all tcp activity and compare what is different between my linux and windows programs. Here are https://gist.github.com/alexbrainman/5cef4b81f3a8ae2f9218#file-linux-txt and https://gist.github.com/alexbrainman/5cef4b81f3a8ae2f9218#file-windows-txt logs for linux and windows. It looks like the difference is in how client handles server closing connection in the middle of large client write. Windows client write fails immediately, followed by client read error. Linux client write fails too, but is followed by successfull read and read EOF after that. I don't think you can expect this all to work reliably accross different OS and environments. I have changed the test this way:
and now it is failing on linux too with:
Alex |
FWIW yes you cannot assume that write+close will result in the client seeing the write before the close, especially if the server does the write+close while the client is doing its own large write. |
I forgot to update this bug with https://golang.org/cl/18105 which fixes the spinning error and log spam. |
CL https://golang.org/cl/18553 mentions this issue. |
Updates golang/go#13434 Change-Id: Icc098d9a6e1af55d36e828fa21d88b967f2f0131 Reviewed-on: https://go-review.googlesource.com/18553 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Updates golang/go#13434 Change-Id: Icc098d9a6e1af55d36e828fa21d88b967f2f0131 Reviewed-on: https://go-review.googlesource.com/18553 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
From windows-amd64-gce builder http://build.golang.org/log/a0906e4fa3713e6512cdff9af6662d1db0faad0d
I can reproduce this here. I don't know what the problem is.
Alex
The text was updated successfully, but these errors were encountered: