file:/ vs file://<host>/ vs file:///

[Rob North]

Daniel Veillard wrote:
> On Thu, Nov 04, 2004 at 08:07:59PM -0500, Daniel Veillard wrote:
> 
...
> Someone finally went though the work of trying to bring a successor 
> to RFC 1738 "file" protocol definition, it is a very early draft,
> prone to be changed a lot before carrying much normative value but
> still worth checking :
> 
> http://www.ietf.org/internet-drafts/draft-hoffman-file-uri-02.txt
> 
> Section 3.3 states:
> 
> 3.3  Use of hostname and host name checking
> 
> The file URI specification calls for using the actual host name as 
> the name authority and allowing it to be omitted.  This practice is 
> rarely followed, and frequently is not checked.  Some applications 
> generate URIs with no authority component at all, such as 
> "file:/this/is/the/path".
> 
> Seems to me that they suggest not using it, but allowing it to be
> processed. But the wording is awfully unclear - probably because they
> know it is a sensitive issue :-) - maybe some feedback is in order. 
> Also it could be a good idea to double-check suggested practice
> within f.d.o. does not conflict with the new draft.
> 
> Daniel
> 

Been following the "file:" URI discussion, and I'm glad to see some 
progress.

The draft for the updated URI spec you gave earlier 
(http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html) appears to
clarify this even more:

In section 3.2.2 it says:

> If the URI scheme defines a default for host, then that default
> applies when the host subcomponent is undefined or when the
> registered name is empty (zero length). For example, the "file" URI
> scheme is defined such that no authority, an empty host, and
> "localhost" all mean the end-user's machine, whereas the "http"
> scheme considers a missing authority or empty host to be invalid.
> 

So, an application should not fail if it is passed a URI of the format
"file:/a/b/c".

What's more, the draft spec gives some suggestions for normalization.

In section 6.2.3 it says:

> Another case where normalization varies by scheme is in the handling of
> an empty authority component or empty host subcomponent. For many scheme
> specifications, an empty authority or host is considered an error; for
> others, it is considered equivalent to "localhost" or the end-user's
> host. When a scheme defines a default for authority and a URI reference
> to that default is desired, the reference should be normalized to an
> empty authority for the sake of uniformity, brevity, and
> internationalization. If, however, either the userinfo or port
> subcomponent is non-empty, then the host should be given explicitly even
> if it matches the default.


Normalization to empty authority implies that "file:///a/b/c" is the
normal form.
(This is only sensible, as this is the only form for no authority that 
is compatible with old URL syntax).
This suggests applications should generate "file:///a/b/c" if at all 
possible. (and *not* "file:/a/b/c" ).

Or course this all assumes that this will make it into the final standard.
I'd hope there will be liaison between f.d.o and IETF to ensure f.d.o 
standards and drafts are in sync with IETF intentions.

Keep up the good work
	-Rob.