Re: [RFC] Pathname Semantics with //

[Jamie Lokier <jamie@shareable.org>]

Christian Mayrhuber wrote:
> //http://somehost:port/foo/bla

While we're here, I'll point out that http://somehost/foo/bla and
http://somehost/foo/bla/ are valid, distinct URLs.

If http://somehost/foo/bla/ exists, many HTTP servers will return it
as the target of a redirect for http://somehost/foo/bla.  The reason
for this is that it's important for any relative URLs in a document to
be resolved relative to the correct base URL of the document.

If we do actually allow file-and-directory objects, it makes sense for
the path _with_ slash on the end (//http://somehost/foo/bla/) to be
accessible as both a file and a directory, mapping to that HTTP
resource, and resources below it in the path hierarchy.

Then relative paths in the resource resolve sensibly in programs which
think they're in the local filesystem.

It also makes sense for the path _without_ slash to be recognisable to
programs as needing the slash.  That could be done by making the path
without slash by a symlink to one with (symlinks are a natural
representation of redirects).  But that seems like a gross violation
of POSIX semantics: we can't really return different objects depending
on the trailing slash.

So instead, it makes sense for either form of the path to be a
file-and-directory object whose type is S_IFDIR, and specifically not
S_IFREG -- but only in the cases where the HTTP transaction to the URL
without a trailing slash returns a redirect to the same URL with a
slash appended.  When the HTTP transaction to the URL without a
trailing slash returns a resource, then it's type in the filesystem
should be S_IFREG, but still a file-as-directory object.

Food for thought.

-- Jamie