net/url: Fails to parse URLs with spaces in scope IDs in 1.6beta2

[calmh]

Test program:

package main

import (
    "fmt"
    "net/url"
)

func main() {
    u, err := url.Parse("tcp://[fe80::cefa:ff:fef3:5fcc%25Wireless%20Network%20Connection]:22000")
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Println("OK:", u)
    }
}

Fine in 1.5.2:

jb@syno:~/tmp $ go version
go version go1.5.2 darwin/amd64
jb@syno:~/tmp $ go run test.go 
OK: tcp://[fe80::cefa:ff:fef3:5fcc%25Wireless%20Network%20Connection]:22000

Errors in 1.6beta2:

jb@syno:~/tmp $ go run test.go 
parse tcp://[fe80::cefa:ff:fef3:5fcc%25Wireless%20Network%20Connection]:22000: invalid URL escape "%20"
jb@syno:~/tmp $ go version
go version devel +66330d8 Wed Jan 13 23:40:13 2016 +0000 darwin/amd64

That's how Windows represents scope IDs.

[bradfitz]

@rsc, you touched this last. Maybe you still remember all the spec rules and Go decisions made?

[rsc]

We started rejecting spaces in host names, which is generally correct. I guess we have to accept spaces in the %-encoded scope section. Ugh.

[rsc]

CL 18855.

[gopherbot]

CL https://golang.org/cl/18855 mentions this issue.

[canton7]

Windows: putting spaces where they don't belong since Windows NT 3.1.

Purely out of interest: Windows uses the Scope ID of the network interface in question as the zone identifier. This is a long, so zones typically have the value %1, %2, etc.

Using the network interface name on Windows seems to be a Go thing. Presumably there's good reason, although it does make taking URLs formatted by Go and parsing them in other languages slightly tricky.

[bradfitz]

/cc @calmh, @mikioh, @alexbrainman for feedback. Where did the OP's URL/scope ID come from?

[calmh]

That's from String() on a net.Addr returned from Read...() on an UDP socket (whatever the exact read method is that returns the packet plus the source address, I'm on mobile currently). We that put that address in as the Host in a url.URL which in turn gets stringified and sent over the network. The other side does url.Parse which results in the above.

[bradfitz]

@rsc, given @calmh's comment, I think your fix above isn't necessary. I think we need to fix the String method instead.

[rsc]

I'm not changing the String method to emit an encoded URL with literal spaces in it. URLs do not have spaces. Full stop.

[rsc]

There's some notion that we should be using %1 instead of %AdapterName, but I don't know where the 1 comes from and I don't know if it works to send it over the network.

[calmh]

As a side note, url.Parse also does not accept spaces in the host name (in the scope ID or otherwise), so that wouldn't be an immediate fix. Perhaps it could be taught to do so, but it seems cleanest to do the escaping as it currently does and then accept that back.