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.