From kde-core-devel  Sat Nov 13 11:44:16 2004
From: Waldo Bastian <bastian () kde ! org>
Date: Sat, 13 Nov 2004 11:44:16 +0000
To: kde-core-devel
Subject: Re: file:///
Message-Id: <200411131244.20737.bastian () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110034635003516
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart4464933.Pay48Uy2uU"

--nextPart4464933.Pay48Uy2uU
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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     =3D ( net_path | abs_path ) [ "?" query ]
>       net_path      =3D "//" authority [ abs_path ]
>       abs_path      =3D "/"  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=
=20
which case the authority is equivalent with"localhost". Note the difference=
=20
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=20
specifically maps to the various possibilities outlined by RFC2396. Since=20
RFC2396 is silent on that, RFC1738 is authorative on the matter. In=20
particular also because RFC2396 only "...revises and replaces
the generic definitions in RFC 1738...", and so leaves the scheme specific=
=20
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 f=
or
> Relative URLs".

We need an absolute URL, relative URLs are only useful if you have a base U=
RL=20
defined against which the relative URLs should be resolved. That's the case=
=20
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 abou=
t=20
what kind of base URL applications SHOULD assume on the command line or=20
anywhere else, but that doesn't make it reality.

Cheers,
Waldo
=2D-=20
bastian@kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian@suse.com  |   http://www.novell.com/products/desktop/eval.html

--nextPart4464933.Pay48Uy2uU
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBBlfOUN4pvrENfboIRAjzSAJsESn47iTIPyg2pgPqaHAduq5JfkwCeMUWh
F1LuNCSoJYUHq0Yj3fvNQjQ=
=mSJ5
-----END PGP SIGNATURE-----

--nextPart4464933.Pay48Uy2uU--