Re: lynx-dev Improper ~/ expansion in file://

[pg]

In a recent note, Klaus Weide said:

> Date: Sun, 22 Nov 1998 16:33:45 -0600 (CST)
> 
> A good question.  I don't know the real answer, but "\\" in Windows (which
> probably would be translated into "//") has a specific meaning, and I seem
> to recall that POSIX or some similar spec for Unix says something like
> "a // at the beginning may have system-defined meaning". (Can anyone
> confirm?)
> 
(I don't have the document handy; this is from memory.)  POSIX notes
that there is a convention of accessing remote filesystems:

    //<hostname>/<pathname>

POSIX tolerates this, but "strongly recommends" that developers
of new systems not implement this convention.  On the other side,
POSIX recommends that application developers not build paths
by grafting a branch onto a stem:

    $STEM'/'$BRANCH

because if STEM is '/', this results in a path beginning with the
treacherous two slashes.  Instead, POSIX recommends:

    $STEM'//'$BRANCH

If STEM is '/', this results in '///'$BRANCH, which begins with
three slashes, and only exactly two leading slashes may introduce
the remote filesystem construct.

A colleague points out that this is likely the genesis of the
URL syntax:

    <scheme>'://'<hostname>'/'path

> Maybe it is only at the beginning of a pathname that "//" should be

Elsewhere, POSIX doesn't allow it to matter.

> preserved, but a function like LYTrimRelFromAbsPath() may get called
> in many places and doesn't generally know if the string is a full
> path.  So the safest thing may be to leave it alone once a "//" somehow
> got into a path.  That is what lynx does, for the most part.  If a user
> enters a path like that, he gets what he deserves (or maybe has a good
> reason).
> 
> A complication is that URL paths and (at least Unux) filesystem paths
> act differently w.r.t. "".  For files, a ".." steps back over multiple
> slashes, but if I read the URL syntax correctly a ".." should step "in
> between" the two slashes, there is a path segment between them that just

Particularly, RFC 1808 details the semantic difference of ending a
URL path with a '/', something that makes no difference in POSIX
paths.  Roughly, if the URL is given as:

    scheme://host/foo/bar/

and the relative URL is X, the current directory is taken to be the
entire URL, and the constructed URL is:

    scheme://host/foo/bar/X

whereas if the base URL had been simply

    scheme://host/foo/bar

the constructed URL is:

    scheme://host/foo/X

-- gil