Split host/port from URI authority

[Eric Anderson]

What is the appropriate way to split apart a host and port from a "server-based naming authority?" This is a string that can be in the form "host:port" or just "host". This is the type of string in URL.Host and http.Request.Host.

net.SplitHostPort() doesn't work because it requires the port to be present. I'd be fine if there was some way to add a default port if no port was present, but I don't find a function to do that either.

You can see the behavior of SplitHostPort in:

https://play.golang.org/p/sEql--3WSq

This doesn't seem all that strange of a need; any protocol that uses URLs would need something like this in order to be able to Dial(). Given that the following code is in net/http, I guess I'm expected to implement the handling myself. Should I file an issue?

// canonicalAddr returns url.Host but always with a ":port" suffix

func canonicalAddr(url *url.URL) string {

addr := url.Host

if !hasPort(addr) {

return addr + ":" + portMap[url.Scheme]

}

return addr

}

// Given a string of the form "host", "host:port", or "[ipv6::address]:port",

// return true if the string includes a port.

func hasPort(s string) bool { return strings.LastIndex(s, ":") > strings.LastIndex(s, "]") }

[Brad Fitzpatrick]

I've written variants of this code a dozen times.

This might be a candidate for the standard library but the name might be hard. net.SplitHostOptionalPort? Little wordy.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Harden]

I would have preferred if the API for JoinHostPort did this automatically - keep the port from the host if present, otherwise add the port.

Maybe net.InjectPort. Or maybe it just makes sense to provide HasPort and still make the user add the port if needed? I think HasPort is the only part that requires knowledge about the possible formats of host:port strings; the rest is quite obvious.

[Brad Fitzpatrick]

On Mon, Sep 14, 2015 at 6:02 AM, Matt Harden <matt....@gmail.com> wrote:

I would have preferred if the API for JoinHostPort did this automatically - keep the port from the host if present, otherwise add the port.

We're not changing JoinHostPort, especially not now.

 

Maybe net.InjectPort. Or maybe it just makes sense to provide HasPort and still make the user add the port if needed? I think HasPort is the only part that requires knowledge about the possible formats of host:port strings; the rest is quite obvious.

We basically already have HasPort: you test if SplitHostPort fails. :)

It's not a beautiful API, but maybe it's enough.

[Matt Harden]

I wasn't suggesting that we change JoinHostPort; just saying I would have preferred that it had been designed that way in the first place.

SplitHostPort can fail for reasons other than a missing port, so it's not identical to HasPort. Also we can't distinguish the types of failure from SplitHostPort without inspecting the error string (which is a horrible idea IMO).

[Brad Fitzpatrick]

yeah, hence my use of "basically".