From kde-core-devel  Sat Nov 13 10:16:49 2004
From: Reinhold Kainhofer <reinhold () kainhofer ! com>
Date: Sat, 13 Nov 2004 10:16:49 +0000
To: kde-core-devel
Subject: Re: file:///
Message-Id: <200411131116.52517.reinhold () kainhofer ! com>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110034102327580
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1511736.gui5chO8IK"

--nextPart1511736.gui5chO8IK
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 b=
e=20
there, otherwise the // are NOT there...

See also appendix A of 2396 for the BNF of the scheme:
      URI-reference =3D [ absoluteURI | relativeURI ] [ "#" fragment ]
      absoluteURI   =3D scheme ":" ( hier_part | opaque_part )
      relativeURI   =3D ( net_path | abs_path | rel_path ) [ "?" query ]

      hier_part     =3D ( net_path | abs_path ) [ "?" query ]
      opaque_part   =3D uric_no_slash *uric

      uric_no_slash =3D unreserved | escaped | ";" | "?" | ":" | "@" |
                      "&" | "=3D" | "+" | "$" | ","

      net_path      =3D "//" authority [ abs_path ]
      abs_path      =3D "/"  path_segments
      rel_path      =3D rel_segment [ abs_path ]

Basically, this even allows URIs without the preceding file:/ . These URIs =
are=20
then relativeURIs (although this is not meant as relative like in "relative=
=20
path", i.e. relative to the current directory).


This is also what was defined in rfc 1808 already in section "2.2.  BNF for=
=20
Relative URLs". Section 2.1 of rfc 1808 is a bit unclear as it speaks only =
of=20
the six components, but not of the delimiters. However, from the descriptio=
n=20
of the components it becomes clear that the preceding delimiter actually=20
belongs to the component. So if no net_loc is used in the URL, the //=20
delimiter is also not supposed to be there.


> That could not be any further from the truth. How URLs should be
> represented is about as clear as the theory of parallel universes! OK I am
> exaggerating a bit, but just read RFC 1738/1808 and then 2396 and tell me
> you do not come away confused more than before you read those RFCs...

=46rom what I can tell, both file:/path/to/something as well=20
as /path/to/something are correct, file:///path/to/something is not, but=20
file://localhost/path/to/something is again correct according to these RFCs.

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

--nextPart1511736.gui5chO8IK
Content-Type: application/pgp-signature

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

iD8DBQBBld8UTqjEwhXvPN0RAqrKAKCAg/iZQ2aTx5UJenbq1sALnWeQfgCcDEa9
C2YmlQulsehY8snjMx68cl0=
=jYNK
-----END PGP SIGNATURE-----

--nextPart1511736.gui5chO8IK--