net: SplitHostPort errors if no port is specified, but not if input ends with a trailing ":"

[dfawley]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

All

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

All

What did you do?

Repro case:
https://play.golang.org/p/etsLIZv_Oz8

What did you expect to see?

An error due to improper "host:port" syntax.

What did you see instead?

An empty port in the result and no error.

[dfawley]

Note that godoc for Listen specifically calls out "127.0.0.1:" as a valid usage (why?), so this behavior cannot be changed unless Listen handles that case manually. I imagine any behavior change here would not be allowed for backward-compatibility reasons anyway, even though omitting the port doesn't appear to be a valid input in the docs for SplitHostPort itself.

[andybons]

@bradfitz

[bradfitz]

IIRC this was a historical accident that we're unable to fix now (I think we tried once?). But we could try again or at least document the meaning of the empty port.

/cc @mikioh @alexbrainman @ianlancetaylor for if they recall.

[ianlancetaylor]

See #14836 and https://tools.ietf.org/html/rfc3986#section-6.2.3 .

[dfawley]

I'm not sure RFC3986 is relevant, because: a) this is not an RFC3986 parser (that's what the url package is for), and b) that section also lists "example.com" as valid, but that input will error when passed to net.SplitHostPort, because it is missing a port.

[mikioh]

"127.0.0.1:" as a valid usage (why?)

IIUC, the form "host:port" is specific to the "net" package of the Go standard library, though the form refers to several RFCs. I can guess that original API designer on the net package API didn't have much time for the form because when I looked at the implementation it didn't treat much enough a) clear isolation between standardized notation and classical, conventional implementation-dependent forms, b) literal IP addresses especially IPv6 literals and c) various meaning and encoding schemes for the form.

For (a), it's clunky but at least accepting empty strings is required for backward compatibility in the case of traffic reception on any unicast and anycast IP addresses of the local system. For (b), we needed a minimal parser for fixing the conflict of the delimiter ":" with IPv6 literals. For (c), this is still the hardest part because no one knows what's the sustainable solution.

As a compromised result, SplitHostPort and JoinHostPort keep focusing on the manipulation of the form with required minimal parsing.

[mikioh]

traffic reception on any unicast and anycast IP addresses ...

traffic reception on any unicast and anycast IP addresses with automatically assigned identifiers, for example, transport service names or literal transport protocol port numbers on the internet protocol suite.