New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dfawley opened this Issue Jun 13, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@dfawley

dfawley commented Jun 13, 2018

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

This comment has been minimized.

dfawley commented Jun 13, 2018

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

This comment has been minimized.

Member

andybons commented Jun 13, 2018

@andybons andybons added this to the Unplanned milestone Jun 13, 2018

@bradfitz

This comment has been minimized.

Member

bradfitz commented Jun 13, 2018

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

This comment has been minimized.

Contributor

ianlancetaylor commented Jun 13, 2018

@dfawley

This comment has been minimized.

dfawley commented Jun 13, 2018

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

This comment has been minimized.

Contributor

mikioh commented Jun 13, 2018

"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

This comment has been minimized.

Contributor

mikioh commented Jun 13, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment