Comment 1:

Labels changed: added priority-later, os-windows, removed priority-triage.

Status changed to Accepted.

Comment 2:

We're not going to get to this for Go 1.2.
It's not obvious to me what the fix is either. Should net/url's behavior really depend
on which OS the program runs on? Does that mean you cannot manipulate Windows file URLs
on Linux machines or vice versa?

Labels changed: added go1.3, removed go1.2maybe.

Status changed to Thinking.

Comment 3:

I didn't have chance to look into this properly. But I think we need to do something
here. Like you suggested, lets leave for after Go 1.2. 
Alex

Comment 4 by mitchell.hashimoto:

Yeah after more thought the unfortunate thing is that it just isn't clear whether the
URL is a Windows file URL or not. Changing the behavior based on the OS that Go runs on
is kind of silly I think. 
I've worked around this at the moment by just stripping the first character and checking
if it exists. 
I'm not sure what Go should do here.

Comment 5:

what do other libraries for other languages do on the problem?

Comment 6:

Labels changed: added release-go1.3, removed go1.3.

Comment 7:

Labels changed: added repo-main.

Comment 8:

I think this is not a bug. For example, we can create directory like follow on unix.
$ mkdir -p 'C:/Program Files/foo/bar'
Whether the url is treated as windows path or not, it depend on the OS which treat the
URL.

Comment 9:

Leaving it as is results in easy to reason behaviour and avoids overcomplicated edge
cases, as can be seen by the mkdir example above.
I tested some other libraries handling of URIs/URLs (on Mac OS X 10.9)
Python 2 and 3
    >>> urlparse('http:///C:/Directory/')
    ParseResult(scheme='http', netloc='', path='/C:/Directory/', params='', query='', fragment='')
    >>> urlparse('http:///Directory/')
    ParseResult(scheme='http', netloc='', path='/Directory/', params='', query='', fragment='')
    >>> urlparse('http://www.google.com/')
    ParseResult(scheme='http', netloc='www.google.com', path='/', params='', query='', fragment='')
Node.JS 0.10.26
    > url.parse('file:///C:/Directory/').pathname
    '/C:/Directory/'
    > url.parse('http:///Directory/').pathname
    '/Directory/'
    > url.parse('http://www.google.com/').pathname
    '/'
Java 1.6.0 (java.net.URL and getPath())
    URL("file:///C:/Directory/");   // => /C:/Directory/
    URL("file:///Directory/");      // => /Directory/
    URL("http://www.google.com/");  // => /
Mono 3.2.7 (System.Uri and AbsolutePath)
    uri = new Uri("file:///C:/Directory/");   // => C:/Directory/
    uri = new Uri("file:///Directory/");      // => /Directory/
    uri = new Uri("http://www.google.com/");  // => /
Of these, only Mono (.Net in general?) will parse the URI differently, removing the
leading '/'' infront of a drive letter.
Given this and reading RFC3986 for Generic syntax for URI
(http://tools.ietf.org/html/rfc3986), it is best to just treat the path as Go currently
does. In addition, reading the file-scheme RFC draft
(http://www.ietf.org/id/draft-kerwin-file-scheme or
https://github.com/phluid61/file-uri-scheme) shows how many edge cases there can be if
we start treating file-schemes, so it might be hard to draw the line for file-scheme
Path parsing? Can we just let the Path be the path as specified by RFC 3986 (in decoded
form as the documentation in net/url states)?
In my view, the current behaviour matches Go's least-surprise property.

Comment 10:

Thank you for the analysis in comment 9. You've convinced me the parsing is correct as
is.
CL 83930046 will add a test that we preserve the current behavior.

Status changed to Accepted.

Comment 11:

This issue was closed by revision 844b625.

Status changed to Fixed.