file:///

[Waldo Bastian]

On Saturday 13 November 2004 11:16, Reinhold Kainhofer wrote:
> Dawit A. wrote:
> > On Friday 12 November 2004 17:34, Thiago Macieira wrote:
> >> Rolf Magnus wrote:
> >> >> The syntax is actually protocol://[host]/path. The // is mandatory.
> >> >
> >> >For what reason? Why is it so absolutely necessary to add a dummy //,
> >> > even if the protocol doesn't support a concept of a host?
> >>
> >> Because "the standard says so".
>
> No, the standard does NOT say so. See section 3 of rfc 2396:
>
>       hier_part     = ( net_path | abs_path ) [ "?" query ]
>       net_path      = "//" authority [ abs_path ]
>       abs_path      = "/"  path_segments
>
> So, if the path has an authority entry (i.e. a host), then the // need to
> be there, otherwise the // are NOT there...

The file protocol has an authority defined. That authority can be empty in 
which case the authority is equivalent with"localhost". Note the difference 
between "not defined" and "defined but empty".

> See also appendix A of 2396 for the BNF of the scheme:

Yes, that defines URIs in general, but not the file: scheme in particular.

What is missing in RFC2396 is a statement that says how the file-scheme 
specifically maps to the various possibilities outlined by RFC2396. Since 
RFC2396 is silent on that, RFC1738 is authorative on the matter. In 
particular also because RFC2396 only "...revises and replaces
the generic definitions in RFC 1738...", and so leaves the scheme specific 
definitions in RFC1738 stand.

> Basically, this even allows URIs without the preceding file:/ . These URIs
> are then relativeURIs (although this is not meant as relative like in
> "relative path", i.e. relative to the current directory).
>
> This is also what was defined in rfc 1808 already in section "2.2.  BNF for
> Relative URLs".

We need an absolute URL, relative URLs are only useful if you have a base URL 
defined against which the relative URLs should be resolved. That's the case 
within a HTML document, but that's not the case on the command line.

There are all kinds of very reasonable assumptions that you COULD make about 
what kind of base URL applications SHOULD assume on the command line or 
anywhere else, but that doesn't make it reality.

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041113/fbf2eb26/attachment.sig>