Re: URIs vs. half-baked URIs [glib PATCH]

[Maciej Stachowiak <mjs noisehavoc org>]

On 24Aug2001 03:20PM (-0400), Daniel Veillard wrote:
> On Fri, Aug 24, 2001 at 11:55:58AM -0700, Maciej Stachowiak wrote:
> > The URI RFC (2396) says both forms are OK, so it's probably better to
> 
>   Not at the same level
> 
> > go with the simpler one. On the other hand, it's good to have code
> 
>   No it's not an hierarchical URI and you can't compute relative
> URI references from it
> 

It is a hierachical URI. I read the RFC before I posted. Did you? I
guess I have to quote from the spec:

     URI that are hierarchical in nature use the slash "/" character
     for separating hierarchical components.  For some file systems, a
     "/" character (used to denote the hierarchical structure of a
     URI) is the delimiter used to construct a file name hierarchy,
     and thus the URI path will look similar to a file pathname. This
     does NOT imply that the resource is a file or that the URI maps to an
     actual filesystem pathname.

        hier_part     = ( net_path | abs_path ) [ "?" query ]

        net_path      = "//" authority [ abs_path ]

        abs_path      = "/"  path_segments


In summary, "file:/foo/bar/something.txt" is a valid hierarchical
URI. 


On the other hand, rfc1738, the URL RFC, claims that `file:' URLs must
include the `//' part, and since there is no superseding RFC for file
URIs, I assume this is still the operative standard. On the other
hand, this same rfc defines a syntax for specifying passwrods in http
and ftp URLs, and this syntax is strongly reprefacted by rfc2396.

This might mean that `file:/foo/bar' is not officially correct even
though all clients I know of accept it:

   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>

   ...

   As 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'.



Daniel, do you know if there's ever going to be an update of rfc1738
that is updated to take rfc2396 into account? It's hard to know which
takes precedence sometimes:

Regards,

Maciej