file:///

[Reinhold Kainhofer]

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

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

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

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

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

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". Section 2.1 of rfc 1808 is a bit unclear as it speaks only of 
the six components, but not of the delimiters. However, from the description 
of the components it becomes clear that the preceding delimiter actually 
belongs to the component. So if no net_loc is used in the URL, the // 
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...

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

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold at 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 maintainer
-------------- 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/9e40a316/attachment.sig>