net/http: Client.Timeout doesn't work when receiving a response from an incomplete WebSocket handshake

[RyougikiMikiya]

Go version

go version go1.23.4 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE='pkg.go'
GOMODCACHE='/root/go/pkg/mod'
GOOS='linux'
GOPATH='/root/go'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/linuxbrew/.linuxbrew/Cellar/go/1.23.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/home/linuxbrew/.linuxbrew/Cellar/go/1.23.4/libexec/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.4'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/root/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/root/gotests/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build670266472=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I encountered a situation where http.Client.Timeout doesn't work as expected when reading response body from an incomplete/fake WebSocket handshake response. Here's a minimal reproduction:
https://go.dev/play/p/i0mxl_6BaZR

What did you see happen?

The client appears to be permanently blocked when reading the response body despite having a client timeout set. The timeout doesn't trigger as expected, and the operation hangs indefinitely.

What did you expect to see?

When reading the response body from an incomplete WebSocket handshake (where server sends handshake headers but no data afterwards), the http.Client.Timeout setting should trigger after the specified timeout duration (5 seconds in this case) while reading the body.

[gabyhelp]

Related Issues

• net/http: ReadTimeout is not honored when ReadHeaderTimeout > ReadTimeout #35626
• net/http: HTTP client hangs indefinitely if the request handler does not return #65526
• proposal: net/http: allow setting timeouts individually in Client #23100 (closed)
• net/http: setting Timeout in http.Client produces unexpected "context canceled" on body.Close #49521 (closed)
• net/http: unexpected timeout while waiting for connection #34595 (closed)
• x/net/http2: timeouts not respected on malformed data frames #57851
• net/http, x/net/http2: TCP connection is not closed after http client request times out after missing RST (TCP) or GOAWAY(HTTP/2) frame #36026
• x/net/http2, net/http: client can hang forever if headers' size exceeds connection's buffer size and server hangs past request time #23559 (closed)
• crypto/tls: TLS handshake timeout #44267 (closed)

Related Discussions

• Http client timeout doesn't work sometimes

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[dr2chase]

@neild @rsc Gaby turned up some interesting looking issues, not sure I am qualified to tell if they are a good match or not.

[gopherbot]

Change https://go.dev/cl/646035 mentions this issue: net/http: propagate client timeout to upgraded connections

[neild]

I think this is the responsibility of the WebSocket implementation to deal with.

Hijacking an HTTP/1 connection transfers ownership of the net.Conn to the caller of Hijack. If the caller wants to set a deadline, they can do so.

[seankhliao]

On the server side, there's Hijack / ResponseController to explicitly take control of the underlying connection.

But this report is about the client side, which does not specify any parameters in the request that it expects to be hijacked, and the client / transport implementation automatically hijacks the connection for you on receiving the headers the server sent.

[neild]

Apologies, I was confusing which side of the connection this is on.

The net/http package documentation on our behavior here is very thin, consisting mostly of this from Response.Body:

As of Go 1.12, the Body will also implement io.Writer on a successful "101 Switching Protocols" response, as used by WebSockets and HTTP/2's "h2c" mode.

I don't believe we can apply a timeout to the body in this case in a backwards-compatible fashion. It's reasonable and expected for a WebSocket connection to be long-lasting, and other protocols which make use of "101 Switching Protocols" may also make long-term use of the connection.

Perhaps we should implement all of net.Conn on the response body in this case, though.

[seankhliao]

What about when you're not expecting an upgrade into websockets or anything else? you'd have what looks like a hung connection.
it seems quite a bit of extra ceremony to bound a request time even if the rest of net.Conn was exposed on the body