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.