bug#6339: url-filename => "/c:/some/file.txt"

[Juanma Barranquero <lekktu@gmail.com>]

On Wed, May 9, 2012 at 11:04 AM, Chong Yidong <cyd@gnu.org> wrote:

> In particular, RFC 3986 explicitly states that
>
>  If a URI contains an authority component, then the path component must
>  either be empty or begin with a slash ("/") character.
>
> That is to say, the / is part of the path.

This means that it is part of the "path" component of the URI, used to
separate and disambiguate, but does not say anything about how that is
interpreted as a a filesystem path. In this case (with no authority):

  file:///C:/windows/path

"/C:/windows/path" is the "path", but it is obviously not a filesystem path.

> So I think we should just explicitly state that the
> FILENAME slot is really PATH and QUERY together, and wash our hands of
> the matter.
>
> This also means that it should be up to callers to convert the FILENAME
> slot (i.e. PATH and QUERY) into proper filenames.  The translation from
> URIs to filenames is scheme-independent anyway, so it shouldn't be
> handled at the level of url-generic-parse-url.

I don't mind which way we fix it, but I'd be glad if we can avoid
snarky and erroneous "Windows does this wrong" comments in the code
while doing it...

    Juanma