URI::file not RFC 1738 compliant?

As far as I can tell, RFC 1738, section 3.10, as well as the BNF in
section 5 explicitly say that file: URI must have two forward slashes
before the optional hostname, followed by another forward slash, and
then the path.

However:

$ perl -MURI::file -e 'print URI::file->new_abs("/foo"), "\n"'
file:/foo

I would have expected "file:///foo". These "one-slash" file: URIs cause
various interoperability problems here and there with applications or
other libraries that require strict RFC compliance. For example,
XML::LibXML::SAX seems to treat "file:/foo" as a literal relative path
from the current directory (ie. "$PWD/file:/foo"), whereas "file:///foo"
works with it as expected.

Would it be possible to have this fixed in URI?

Re: URI::file not RFC 1738 compliant?

Ville Skyttä writes:

> As far as I can tell, RFC 1738, section 3.10, as well as the BNF in
> section 5 explicitly say that file: URI must have two forward slashes
> before the optional hostname, followed by another forward slash, and
> then the path.

RFC 1738 is becoming a bit stale. I do believe that the intent is for
'file' URIs to also follow the RFC 2396 syntax for hierarchical
namespaces which clearly states at the 'authority' is optional.

absoluteURI =3D scheme ":" ( hier_part | opaque_part )
hier_part =3D ( net_path | abs_path ) [ "?" query ]
net_path =3D "//" authority [ abs_path ]
abs_path =3D "/" path_segments

> However:
>=20
> $ perl -MURI::file -e 'print URI::file->new_abs("/foo"), "\n"'
> file:/foo
>=20
> I would have expected "file:///foo".

I just find 'file:///foo' very ugly so I try to avoid using the
triple slash whenever I can. There is also a slight semantic
difference between these two forms. If the authority is missing it
means that it is unknown, while authority of "" is documented to be
synonym for "localhost". Perhaps this can be used to argue that
'file:///foo' is more correct.

> These "one-slash" file: URIs cause
> various interoperability problems here and there with applications or
> other libraries that require strict RFC compliance. For example,
> XML::LibXML::SAX seems to treat "file:/foo" as a literal relative path
> from the current directory (ie. "$PWD/file:/foo"), whereas "file:///foo"
> works with it as expected.

Do you have other examples?

> Would it be possible to have this fixed in URI?

Sure. Especially if I'm told about more apps that can't inter operate
with authority-less-file-URIs. I might want to make it an option.

Regards,
Gisle

Re: URI::file not RFC 1738 compliant?

* Gisle Aas wrote:
>> As far as I can tell, RFC 1738, section 3.10, as well as the BNF in
>> section 5 explicitly say that file: URI must have two forward slashes
>> before the optional hostname, followed by another forward slash, and
>> then the path.
>
>RFC 1738 is becoming a bit stale. I do believe that the intent is for
>'file' URIs to also follow the RFC 2396 syntax for hierarchical
>namespaces which clearly states at the 'authority' is optional.

http://www.ietf.org/internet-drafts/draft-hoffman-file-uri-0 0.txt has
been published a few weeks ago, and there is an (ongoing?) discussion
http://lists.w3.org/Archives/Public/uri/2004Aug/thread.html# 58 on the
future of the draft.

>Sure. Especially if I'm told about more apps that can't inter operate
>with authority-less-file-URIs. I might want to make it an option.

A C# program with

Console.WriteLine((new Uri("file:///x")).LocalPath);
Console.WriteLine((new Uri("file:///x:/y")).LocalPath);
Console.WriteLine((new Uri("file:///x|/y")).LocalPath);
Console.WriteLine((new Uri("file://x/y")).LocalPath);
Console.WriteLine((new Uri("file:/x")).LocalPath);

running on Microsoft .NET 1.1 would print

\\x
x:\y
x:\y
\\x\y

and then

Unhandled Exception: System.UriFormatException: Invalid URI:
The format of the URI could not be determined.

for the file:/x case.

Re: URI::file not RFC 1738 compliant?

Bjoern Hoehrmann writes:

> Unhandled Exception: System.UriFormatException: Invalid URI:
> The format of the URI could not be determined.

Ok. URI-1.32 has just been uploaded and it revise how we map filenames
to file URIs. Some examples with the new module:

$ perl -MURI::file -le 'print URI::file->new("foo", "unix")'
foo
$ perl -MURI::file -le 'print URI::file->new("/foo", "unix")'
file:///foo
$ perl -MURI::file -le 'print URI::file->new("foo", "win32")'
foo
$ perl -MURI::file -le 'print URI::file->new("/foo", "win32")'
file:///foo
$ perl -MURI::file -le 'print URI::file->new("//h/foo", "win32")'
file:////h/foo
$ perl -MURI::file -le 'print URI::file->new("c:foo", "win32")'
file:///c:foo
$ perl -MURI::file -le 'print URI::file->new("c:\\foo", "win32")'
file:///c:/foo

Re: URI::file not RFC 1738 compliant?

On Mon, Sep 06, 2004 at 10:10:16PM -0700, Gisle Aas (gisle@ActiveState.com) wrote:
> I just find 'file:///foo' very ugly so I try to avoid using the
> triple slash whenever I can. There is also a slight semantic

I agree it's ugly. It seems to me that Subversion is very picky about
it, though, FWIW.

xoxo,
Andy

--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance