Related Issues and Documentation

• net/url: no Parse error with invalid port in IPv4 addresses (revert) #14860 (closed)
• affected/package: url.Parse #51358 (closed)
• net/url: Parse documentation does not adequately explain escaping rules or RFC compliance #30611
• net/url: Parse not working correctly for a non absolute URL with port. #22955 (closed)
• url.Parse() wrongly assumes scheme for schema-less hosts with port #47955 (closed)
• net/url: make URL parsing return an error on IPv6 literal without brackets #31024
• net/url: Parse can't parse url like 10.88.237.69:4222 #21415 (closed)
• net/url: no default port information after parse URL without explicit port #51329 (closed)
• net/url: URL allows malformed query round trip #22907
• net/url: url.Parse returns an error while parsing 192.168.210.111:8080 #30362 (closed)

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

Change https://go.dev/cl/613035 mentions this issue: net/url: return an error if port is out of range

CC @neild, @rsc.

The net/url package tries to follow RFC 3986, which does not impose any limit on the port number. In particular net/url works for schemes other than http, and there is no requirement that it based on TCP. Admittedly in practice it is based on TCP, so this may be splitting hairs. But I'm concerned that adding this kind of check will break existing working code.

Naturally actually attempting to use an HTTP URL with a large port will fail with an error like dial tcp: address 70000: invalid port.

I'm not really opposed to making this kind of change, I just want to raise the opposing viewpoint.

I recall a bit the frustration that occurred when we introduced ports needing to be strictly decimal. There were a few libraries (particularly MySQL’s driver) that broke because their DSNs were using tcp(...) encapsulated authority sections so that they could support TCP and unix(...) for Unix sockets.