bug#5345: Password asked when visiting a file in a lightweight checkout

[Lennart Borgman]

On Sun, Jan 10, 2010 at 3:10 PM, Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> On Sat, Jan 09 2010, Juanma Barranquero wrote:
>
>> According to RFC 1738 ("Uniform Resource Locators (URL)"),
>> section 3.10 ("FILES"), the syntax is
>>
>>      file://<host>/<path>
>>
>> i.e., the slashes are separators. And "[a]s a special case, <host> can
>> be the string "localhost" or the empty string; this is interpreted as
>> `the machine from which the URL is being interpreted'.". So
>> file:///C:/path is a perfectly valid URL for a local file on Windows,
>> as a shorthand for file://localhost/C:/path. I'm surprised Unix URLs
>> for absolute paths do not start with file:////.
>
> I think the RFC assumes that the leading "/" is not part of the
> directory name, so file://<host>/<path> with <host> = localhost and
> <path> = /etc/fstab (etc/fstab relative to /) becomes
> file:///etc/fstab just like /pub/README on ftp.gnu.org is written as
> ftp://ftp.gnu.org/pub/README and not ftp://ftp.gnu.org//pub/README


That sounds like a plausible reading to me. Shouldn't this then mean
that file://c:/some/file.txt is correct, but that
file:///c:/bad/example.txt is wrong?


> ,----[ rfc1738 ]
> | 3.10 FILES
> |
> |    The file URL scheme is used to designate files accessible on a
> |    particular host computer. This scheme, unlike most other URL schemes,
> |    does not designate a resource that is universally accessible over the
> |    Internet.
> |
> |    A file URL takes the form:
> |
> |        file://<host>/<path>
> |
> |    where <host> is the fully qualified domain name of the system on
> |    which the <path> is accessible, and <path> is a hierarchical
> |    directory path of the form <directory>/<directory>/.../<name>.
> `----
>
> Bye, Reiner.
> --
>       ,,,
>      (o o)
> ---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
>
>
>
>
>