search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.66k stars 17.62k forks source link

x/net/http2: deal with half-closed remote in Transport, flaky TestTransportResPattern_c0h1d0t0, TestTransportResPattern_c1h2d0t0 #16029

Open mikioh opened 8 years ago

mikioh commented 8 years ago

See https://build.golang.org/log/6c16a5f66e28811897fa9ff2818873f56a9a128c and https://build.golang.org/log/5ea1f443a67a371b9acdebeee89cc802345ce5fb.

--- FAIL: TestTransportResPattern_c0h1d1t0 (0.00s)
    transport_test.go:664: client: RoundTrip: http2: stream closed
FAIL
FAIL    golang.org/x/net/http2  7.585s
mikioh commented 8 years ago

Also https://build.golang.org/log/11add19306c4c449d8d05e6b3fb05129b0407ed6

--- FAIL: TestTransportResPattern_c1h2d0t0 (0.00s)
    transport_test.go:664: client: RoundTrip: http2: stream closed
FAIL
FAIL    golang.org/x/net/http2  33.617s
bradfitz commented 8 years ago

This is just a bug in the x/net/http2 test. func testTransportResPattern needs to wait to response until the DATA frame arrives when withData is true.

Removing the Go1.7Maybe label.

bradfitz commented 8 years ago

Actually, it looks like the http2.Transport doesn't handle half-closed situations well.

The server should be able to keep reading the client's request body even after having replied. This is much sketchier in http1, but http2 is clear that it should work.

Somewhat low priority to fix properly, but we can at least fix the failing tests in the meantime.

gopherbot commented 8 years ago

CL https://golang.org/cl/24970 mentions this issue.