net/url: Parse can no longer parse PostgreSQL URLs with multiple hosts

[jackc]

Go version

go version go1.26-devel_8aa1efa223 Sat Oct 11 08:51:54 2025 -0700 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/jack/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/jack/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/f_/ys54bt8s5v54k1rqhs6jt92m0000gn/T/go-build2137266325=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/jack/dev/pgx/go.mod'
GOMODCACHE='/Users/jack/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/jack/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/jack/dev/vendor/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/Users/jack/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/jack/dev/vendor/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.26-devel_8aa1efa223 Sat Oct 11 08:51:54 2025 -0700'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

https://github.com/jackc/pgx/ uses url.Parse to parse PostgreSQL URL connection strings. PostgreSQL URL connection strings allow comma separated host:port pairs. e.g. postgres://jack:secret@foo:1,bar:2,baz:3/mydb?sslmode=disable for high availability connections.

What did you see happen?

As of e3be2d1 I get an error. I've reduced the differing behavior to the following test:

package pgx_test

import (
	"net/url"
	"testing"
)

func TestParseURL(t *testing.T) {
	u, err := url.Parse("postgres://jack:secret@foo:1,bar:2,baz:3/mydb?sslmode=disable")
	if err != nil {
		t.Fatal(err)
	}

	if u.Host != "foo:1,bar:2,baz:3" {
		t.Errorf("unexpected host: %s", u.Host)
	}
}

I get this error:

jack@glados ~/dev/pgx ±master⚡ » got -run=TestParseURL
--- FAIL: TestParseURL (0.00s)
    url_test.go:11: parse "postgres://jack:secret@foo:1,bar:2,baz:3/mydb?sslmode=disable": invalid port ":1,bar:2,baz:3" after host
FAIL
exit status 1
FAIL	github.com/jackc/pgx/v5	0.198s

What did you expect to see?

This may be an example of Hyrum's Law. Perhaps it never should have worked. But it used to work and now it doesn't.

If the new behavior stays it will mean pgx will need its own URL parser to preserve existing behavior and compatibility with PostgreSQL URLs.

[gabyhelp]

Related Issues

• net/url: `Parse` and `ParseRequestURI` permissively accepts trailing colon after port #75223 (closed)
• net/url: mysql://signer@tcp(mysql:3306)/notarysigner no longer parses after 1.12.8 #33646 (closed)
• affected/package: url.Parse #51358 (closed)
• net/url: inconsistent Parse error with missing port #12200 (closed)
• import/path: issue title #74535 (closed)
• net/url: func parse(rawURL string, viaRequest bool) (*URL, error) #63280 (closed)
• net/url: mysql://boulder@tcp(localhost:3306)/foo no longer parses #12023 (closed)
• net/url: parsing URLs with port > 65536 should fail #69443 (closed)
• net/url: Parse does not permit percent escapes in host #30844 (closed)
• net/url: url.Parse() does not allow `/` in http basic auth password #72013 (closed)

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

[seankhliao]

It should never have used url.Parse to parse something that isn't a single url.

Closing as working as intended.

[neild]

net/url should never have accepted invalid URLs with colons in the authority, but it did.

It's a bit late for us to complain that people took advantage of behavior that's over a decade old at this point. Reopening to decide what we should do here.

[neild]

It's not a pretty solution at all, but my inclination is to make net/url exempt URLs with a "postgres" scheme from strict validation of colons in the authority.

A few alternatives I've considered:

• Leave things as-is, break Postgres URL parsing, let users deal with the fallout. Not appealing. I think it's debatable whether this is a compatibility promise violation, but it's not nice to Postgres users.
• Flip the default back to urlstrictcolons=0 forever. Users can opt in to strict validation, but we default to lax validation. This is not appealing, since most users are better served by strict validation. (Nobody wants to accept https://localhost:80:443/, and nobody wants https://::1/ to be interpreted URL with a hostname of ":" and port of "1".)
• Flip the default back to urlstrictcolons=0 for one release to give the ecosystem more time to adjust. Better than either the above options.
• Enable strict validation for only certain URL schemes: http and https definitely, maybe ftp? But how do we determine which schemes to validate? Should we include gopher? smtp?

RFC 3986 is quite clear that colons can appear in the host subcomponent only as part of a bracketed address. Sticking to strict validation of colons in the host subcomponent by default, with exceptions for schemes which rely on non-RFC 3986-compliant parsing, seems like a decent balance between correctness and backwards compatibility.

[seankhliao]

I'm reminded of something I saw recently: bluesky-social/atproto-website#417
It seems people just put whatever they want after ://.

imo, in the long term, postgres is better served by forking the url parser and properly representing multiple hosts in the parsed result.

[gopherbot]

Change https://go.dev/cl/722300 mentions this issue: net/url: permit colons in the host of postgresql:// URLs

[neild]

From the perspective of net/url, we'd be clearly better off if we'd never permitted colons in the host subcomponent.

I don't think we should add support for additional nonconformant URL-shaped schemes in the future. For example, I don't think we should special-case at://, unless there's existing code in the ecosystem depending on net/url parsing at:// URLs with colons in them.

Special casing existing URL schemes where users depend on our existing lenient behavior lets us tighten the restrictions where it counts (http and https in particular) while minimizing overall ecosystem harm.