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

[Chong Yidong]

Ressurrecting this discussion...

I just looked at the relevant code and at RFC 3986, and I think the
problem is that the url object returned by url-generic-parse-url has
badly named slots.  That function ought to be following the RFC, instead
of imposing its own interpretation of things.  So the FILENAME slot,
which is returned by url-filename, should really be two slots, PATH and
QUERY, whose meanings are unambiguously defined in the URI spec.  And
there should be no expectation that the PATH part corresponds to a
filename.

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.

Unfortunately, it's inconvenient to change the contents of the struct
now, since that means changing the arglist of the url-parse-make-urlobj
constructor; that constructor is already called from Tramp, and maybe
other packages.  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.