net/http: should never return EOF without additional context

[timoffex]

Go version

1.23.4

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/timoffex/Library/Caches/go-build'
GOENV='/Users/timoffex/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/timoffex/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/timoffex/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.4/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.4'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/timoffex/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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 arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/v0/mtcq4gwj13q7lzyj4fsq5hz40000gp/T/go-build809904257=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

I maintain a library that has a portion written in Go. Every once in a while, our users encounter issues caused by HTTP requests failing with just the message "EOF", for instance

{"time":"2024-10-09T11:33:30.483338864-04:00","level":"DEBUG","msg":"[ERR] POST ---URL--- request failed: Post \"---URL---\": EOF"}

The outer portion of this message ("[ERR] POST ... failed:") comes from the hashicorp/retryablehttp package. The inner portion is from net/http.

The message is unhelpful and does not help me narrow down the issue, other than that it's a protocol problem (which is also not at all obvious). Users who experience this tend to have unique network configurations, and failures are consistent but don't happen for all kinds HTTP requests made by the client (certain requests consistently work, and other requests consistently fail). Without more context, it's very hard to help users debug their configurations.

It would be massively helpful if net/http simply used fmt.Errorf("...: %w", err) in a few places. Likewise for x/net/http2 (I don't know how to tell which we're using).

What did you see happen?

net/http returns EOF from RoundTripper.Do()

What did you expect to see?

More context about at what point the failure occurred.

[gabyhelp]

Related Issues

• net/http: EOF returned from http.Transport #53472
• net/http: Transport.RoundTrip errors could be more informative #13667
• net/http: Post http://example.com: net/http: HTTP/1 transport connection broken: readLoopPeekFailLocked: EOF #15446 (closed)
• net/http: HTTP CONNECT failures should return a more helpful error #38143 (closed)
• net/http: possible race on persistConn.roundtrip vs. persistConn.readloop in transport when using httptrace #59310
• net/http: Errors from persistConn.readLoop not returned to client still writing a request #62447
• net/http: request.Body.Close() can be called after RoundTrip() returns #58521 (closed)
• net/http: check connection from pool before use #51202
• net/http: Timeout while reading response body gives unexposed http.httpError #58279

Related Discussions

• http.Client.Do() returning EOF error rarely but predictably

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

[seankhliao]

Duplicate of #53472