[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6339: url-filename => "/c:/some/file.txt"
From: |
Juanma Barranquero |
Subject: |
bug#6339: url-filename => "/c:/some/file.txt" |
Date: |
Sun, 25 Sep 2011 02:02:03 +0200 |
On Sun, Sep 25, 2011 at 01:42, Andreas Schwab <schwab@linux-m68k.org> wrote:
> If you interpret the local part as an absolute
> file name you have to prepend a slash after decomposing. If not, then
> file:///etc/hosts wouldn't work as probably intended.
Of course. But that's not the point. The point is that how do you
interpret the local part is only important *after* decomposing the
URI. It's not url-generic-parse-url's task to do any interpretation.
Its docstring says just this:
Return an url-struct of the parts of url.
The CL-style struct contains the following fields:
TYPE USER PASSWORD HOST PORTSPEC FILENAME TARGET ATTRIBUTES FULLNESS.
It says nothing of interpreting any of it, and specifically FILENAME,
POSIX-style. And if it does interpret it POSIX-style it is wreaking
havoc with Windows file: URIs (that's the whole point of this bug
report).
So, of course I agree with you when you say "If you interpret the
local part as an absolute file name you have to prepend a slash after
decomposing.", or more precisely, with what Lennart said previously:
> This is not about absolute path in the platform syntax. It is an
> absolute path as understood as part of an URL. That has to be
> translated to a platform path.
But this discussion is not about how to use the decomposed URI, is
about whether the decomposition is correct, or buggy (and so should be
fixed). I think the RFCs (the one I quoted and the ones you quoted)
show clearly that the current decomposition is erroneous, though
convenient for POSIX systems.
At this point, I can see only two options:
- Fix the bug, and fix also the places where the return value of
url-generic-parse-url / url-filename is assumed to be a POSIX absolute
path.
- Leave it as is, and implement some ad hoc hack to make it work with
Windows file: URIs.
Juanma
- bug#6339: url-filename => "/c:/some/file.txt", (continued)
- bug#6339: url-filename => "/c:/some/file.txt", Jason Rumney, 2011/09/23
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/24
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/24
- bug#6339: url-filename => "/c:/some/file.txt", Andreas Schwab, 2011/09/24
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/24
- bug#6339: url-filename => "/c:/some/file.txt", Andreas Schwab, 2011/09/24
- bug#6339: url-filename => "/c:/some/file.txt",
Juanma Barranquero <=
- bug#6339: url-filename => "/c:/some/file.txt", Lennart Borgman, 2011/09/24
- bug#6339: url-filename => "/c:/some/file.txt", Richard Stallman, 2011/09/24