cmd/go: standard library tests fail with GO111MODULE=auto

[rittneje]

Go version

go version go1.22.6 darwin/amd64

Output of go env in your module/workspace:

GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/tmp/.gocache'
GOENV='/Users/rittneje/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/rittneje/go/pkg/mod'
GONOPROXY='[REDACTED]'
GONOSUMDB='[REDACTED]'
GOOS='darwin'
GOPATH='/Users/rittneje/go'
GOPRIVATE='[REDACTED]'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/rittneje/go1.22.6'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/Users/rittneje/go1.22.6/pkg/tool/darwin_amd64'
GOVCS='[REDACTED]'
GOVERSION='go1.22.6'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD=''
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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/kf/kr7_s3xx0l12zbj3jrn082hmzy5gvy/T/go-build1131392119=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

go test net/http -v -run=^TestReadResponseErrors$

What did you see happen?

=== RUN TestReadResponseErrors
response_test.go:944: status "200 OK" "Content-Length:\r\nContent-Length:\r\n\r\nGophers\r\n": unexpected success; want error with substring "invalid empty Content-Length"
--- FAIL: TestReadResponseErrors (0.00s)
FAIL
FAIL net/http 0.636s
FAIL

What did you expect to see?

=== RUN TestReadResponseErrors
--- PASS: TestReadResponseErrors (0.00s)
PASS
ok net/http 0.278s

This is because GODEBUG is not getting the expected default value due to GO111MODULE=auto.

Explicitly running GO111MODULE=on go test net/http -v -run=^TestReadResponseErrors$ causes it to pass.

[gabyhelp]

Related Issues and Documentation

• httptest: empty response (EOF) #46838 (closed)
• net/http: TestTransportEventTraceRealDNS fails consistently #17670 (closed)
• go test broken with parameters #33869 (closed)
• net/http/httputil: DumpResponse return error when ContentLength=2 with Body length 0, but it's a response for http.MethodHead request #42478
• Test #67906 (closed)
• test #61922 (closed)
• "Go test -v" running for all tests's result(pass) is different form when I'm running individual test(fail) #42966 (closed)
• net/http: flaky tests on macOS #33585 (closed)
• go/build: TestMissingImportErrorRepetition fails based on GONOPROXY and GOPRIVATE #35986 (closed)
• net/http: No error with http2 client on empty reply body and content-length != 0 #46071 (closed)

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

[ianlancetaylor]

I can't recreate this problem, either with Go 1.22 or HEAD. For me the test passes.

This is because GODEBUG is not getting the expected default value due to GO111MODULE=auto.

I don't see what in the test depends on GODEBUG.

[rittneje]

@ianlancetaylor The test is dependent upon httplaxcontentlength.

Go 1.22 made it an error for a request or response read by a net/http client or server to have an empty Content-Length header. This behavior is controlled by the httplaxcontentlength setting.

Also, what is your working directory when you run the test? If you run it from $GOROOT/src then it will pass, but running from elsewhere will cause it to fail as described.

Also, be sure to clear your test cache first, due to the bug I filed in #69203.

[ianlancetaylor]

Thanks. I see the problem if I run go test from a different directory that does not contain a go.mod file. And I see the problem with GO111MODULE=off even if I run it from $GOROOT/src.

As you probably know, the problem is because in non-module mode the go tool assumes that it is running Go version 1.20. It looks through the list of entries in the internal/godebugs package. For each one whose Changed value is less than 20, it explicitly sets the Old value. The effect today is

asynctimerchan=1,gotypesalias=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,netedns0=0,panicnil=1,randseednop=0,tls10server=1,tls3des=1,tlskyber=0,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1

I think the right fix is going to be to change the cmd/go tool so that when testing the standard library we look at the go.mod file in the standard library. After all, the go.mod file from where cmd/go is run doesn't really matter when testing the standard library.

And we should say that testing the standard library with GO111MODULE=off simply doesn't work.

CC @matloob @samthanawalla