Re: URI::file not RFC 1738 compliant?

Ville Skyttä <ville.skytta@xxxxxx> 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   = scheme ":" ( hier_part | opaque_part )
      hier_part     = ( net_path | abs_path ) [ "?" query ]
      net_path      = "//" authority [ abs_path ]
      abs_path      = "/"  path_segments

> However:
> 
>   $ perl -MURI::file -e 'print URI::file->new_abs("/foo"), "\n"'
>   file:/foo
> 
> 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