net/http: do not enable HTTP/2 extended connect by default

[rthellend]

Go version

go version 1.24rc1

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/robin/.cache/go-build'
GODEBUG=''
GOENV='/home/robin/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2734898122=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/robin/src/tlsproxy/go.mod'
GOMODCACHE='/home/robin/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/robin/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/robin/src/goroot'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/robin/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/robin/src/goroot/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.24-705b5a569a Fri Jan 3 14:40:11 2025 -0800'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

This change, which should be autogenerated appears to have picked up an unintended change to src/net/http/h2_bundle.go

https://go-review.googlesource.com/c/go/+/631336

https://go-review.googlesource.com/c/go/+/631336/2/src/net/http/h2_bundle.go

all: update vendored dependencies [generated]

The Go 1.24 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.

For [#36905](https://go.dev/issue/36905).

[git-generate]
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=master

What did you see happen?

The change to h2_bundle.go that enables the Extended Connect Protocol is undocumented.

What did you expect to see?

The change should either be documented or removed.

[seankhliao]

The change looks intentional (part of #49918).
I think this just needs a release note?

cc @WeidiDeng @neild

[rthellend]

I doubt this is actually intentional. It will break existing websocket implementations. If anything, the feature should be optional (off by default).

Browsers will start trying to open websockets using h2, and it will fail unless there is code in the server to handle those requests.

[gabyhelp]

Related Issues

• packaging+docker: Outdated go.mod used in images and tarball #60297 (closed)

Related Code Changes

• net/http: update bundled http2
• net/http: more HTTP/2 tests and fixes
• net/http: update bundled http2
• net/http: update bundled http2, add h2 Transport.IdleConnTimeout tests
• net/http: update bundled x/net/http2
• net/http: update h2_bundle.go
• net/http: update bundled http2
• net/http: update bundled x/net/http2
• net/http: use RFC 723x as normative reference in docs

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

[rthellend]

Here's a boiled down example that demonstrates the problem: https://gist.github.com/rthellend/e77264034eb761ccf32abd274792775a

2025/01/04 16:19:27 HTTP/2.0 GET /
2025/01/04 16:19:27 HTTP/2.0 CONNECT /websocket
2025/01/04 16:19:27 ERR websocket: the client is not using the websocket protocol: 'upgrade' token not found in 'Connection' header

[prattmic]

This was added in https://go.dev/cl/610977. I'll leave it to @neild to say whether it is intentional/correct, but I also want to point out that #70728 was filed as a follow-up issue, which I've tentatively made a release blocker as well, and the CL has another comment about a potential deadlock with no issue.

[WeidiDeng]

The exact proposal is here. And according to rsc, this should be on by default. To turn this flag off, GODEBUG=http2xconnect=0 is used. As said by @rthellend, it will break existing codes if that env isn't specified because the server advertised it can handle websockets over h2 but the handler still uses h1 upgrade mechanics which isn't compatible with h2 websockets. And some of the most used browsers will try to use websockets over h2 if the server advertises support.

#70728 is when the golang http2 client tries to use extended connect to establish a websocket connection over h2, which can only happen if user tries to use the new websocket upgrade mechanics.

[rthellend]

It's not clear to me that @rsc understood that this will break all websocket implementations when he said this didn't have to be opt-in.

#53208 (comment)

I don't think it has to be opt-in but it probably needs a GODEBUG to provide a fallback when hitting endpoints or middleware that is buggy when extended CONNECTs are involved. http2xconnect=0 or something like that.

[neild]

To summarize:

https://go-review.googlesource.com/c/net/+/610977 implements proposal #49918, adding support for HTTP/2 Extended CONNECT (RFC 8441) to x/net/http2.

Extended CONNECT is a protocol extension permitting an HTTP/2 client to negotiate a protocol switch on an HTTP/2 stream. The primary (only?) use of extended CONNECT is to bootstrap the WebSocket protocol.

Extended CONNECT support is negotiated while establishing an HTTP/2 connection. With this change, x/net/http2 servers now advertise support for extended CONNECT. Browsers interpret this as the server indicating support for WebSocket-over-HTTP/2. This causes problems, because WebSocket-over-HTTP/2 requires support from the server's WebSocket layer as well as the HTTP/2 layer.

This indicates that, contrary to our belief, advertising extended CONNECT support is not a backwards-compatible change. We should revert the change to x/net to advertise extended CONNECT support by default, and add a mechanism by which servers can explicitly enable it.

[gopherbot]

Change https://go.dev/cl/641475 mentions this issue: http2: disable extended CONNECT by default

[cdujeu]

Sorry i i'm wrong, I do not fully get the link between go versions and golang.org/x packages versioning.

For those having the issue, this has been introduced in golang.org/x/net v0.32.0 , so for me the http2xconnect flag is required although I'm building with go 22 or 23... Reverting to v0.31.0 fixes that (but brings back a known vulnerability 😭).

Will the backport you are referring to also be part of a golang.org/x/net next version ?

Thanks!

[gopherbot]

Change https://go.dev/cl/642606 mentions this issue: [internal-branch.go1.24-vendor] http2: disable extended CONNECT by default