cmd/go: host-only .netrc entries do not match HTTPS proxy URLs with explicit ports #81253

Go version

go version go1.27.0 linux/arm64

The issue also reproduces with go version go1.26.0 linux/arm64, the other
currently supported major release.

Output of go env in your module/workspace

The reproducer uses the official golang:1.27.0 image. Relevant output from
go env before the per-run proxy variables are applied:

GOARCH='arm64'
GOAUTH='netrc'
GOMOD='/dev/null'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTOOLCHAIN='local'
GOVERSION='go1.27.0'
GOWORK=''

What did you do?

I ran this self-contained reproducer:

https://github.com/savinmikhail/go-netrc-port-reproducer

go run .

It starts an ephemeral HTTPS module proxy on a non-default port with a
temporary trusted CA and synthetic Basic credentials. It then runs go mod download in the official Go 1.26.0 and 1.27.0 Docker images with a GOPROXY
of the form https://host.docker.internal:<port>.

The reproducer compares these two .netrc entries:

machine host.docker.internal login test-user password test-password
machine host.docker.internal:<port> login test-user password test-password

The cases use separate temporary module caches. The proxy records whether an
Authorization header was received, without printing its value.

What did you see happen?

The host-only entry was not used. The proxy received no Authorization
header and returned 401. Including the port in the machine entry made the
same .info, .mod, and .zip requests succeed:

Go 1.26.0, machine host.docker.internal:               failed (requests=2, with Authorization=0)
Go 1.26.0, machine host.docker.internal:<port>:        succeeded (requests=3, with Authorization=3)
Go 1.27.0, machine host.docker.internal:               failed (requests=2, with Authorization=0)
Go 1.27.0, machine host.docker.internal:<port>:        succeeded (requests=3, with Authorization=3)
Reproduced: a host-only .netrc entry is ignored when GOPROXY uses an explicit port.

What did you expect to see?

I expected a host-only machine entry to match that host independently of an
explicit port, and therefore for the requests to include Basic credentials.

This was the behavior established by #37130 and CL 218418. In that issue, the
host-only behavior was considered correct and consistent with curl's .netrc
matching. Requiring machine host:port again also means configurations that
followed the resolution of #37130 no longer work for proxies on non-default
ports.

The current implementation appears to explain the result. GOAUTH=netrc
stores the .netrc machine string as a credential-cache prefix, while
loadCredential starts matching at url.Host, which includes an explicit
port. Walking up URL path prefixes can reach host:port, but never host.

An earlier implementation had been corrected to use req.URL.Hostname() by
CL 218418. Commit 71048da later changed that
lookup to req.Host, which includes the port for ordinary outbound requests.
The GOAUTH credential cache introduced afterward preserves the same observable
behavior.

Custom GOAUTH command prefixes may reasonably remain port-specific. This
report is specifically about the built-in netrc method retaining .netrc
machine-name semantics.

I searched open golang/go issues for combinations of netrc, GOPROXY,
explicit port, and machine host:port. I found the closed #37130, but no
open issue tracking the regression.