net/url: URL.String can return invalid string if given invalid URL.Path

[eaigner]

When a path is set on a URL without a leading slash, String() does not add one

http://play.golang.org/p/AQR3kXpXrf

I don't know if is intended behavior, but it I guess it would be better handled with
automatically pre-pending the slash since the documentation for this function also states

    "String reassembles the URL into a valid URL string."

which is obviously not the case here.

[scottferg]

Comment 1:

Seems like String() is ignoring the lack of a slash when it writes the path to the
output. In your provided case, if you add the leading slash when setting u.Path it works
fine. I've attached a proposed fix for the issue in url.go, as well as a source file
that shows which cases work and which do not.  I can push up a CL if there's interest.

Attachments:

1. slash.go (338 bytes)
2. urlfix.diff (423 bytes)

[scottferg]

Comment 2:

CL submitted as https://golang.org/cl/11698045/

[mitchellh]

Comment 3:

I just ran into this as well and would consider this a bug. 
According to the URL RFC (1738), not section 3.1 (and all following schemas), the
prefixed "/" is expected to exist and must be there if there is a path.

[rsc]

Comment 4:

Still not sure whether this is just a doc fix.

Labels changed: added priority-later, go1.2, removed priority-triage.

Status changed to Accepted.

[mitchellh]

Comment 5:

I would consider this a bug solely based on this Go Playground example:
http://play.golang.org/p/XWK4tgBqYo
I would consider parsing the String() version of a *URL to turn back into an identical
representation of the URL that made the string. However, due to this bug, it turns into
a completely different (and wrong) URL object.

[rsc]

Comment 6:

@xmitchx, the input you are passing to u.String is not a valid URL. No valid URL can
decode back to that identical struct, because any decoded URL will put a leading / on
the path.

[bradfitz]

Comment 7:

This issue was closed by revision 39679ca.

Status changed to Fixed.