Re: Treatment of trailing slash after directory name

yandros@MIT.EDU
Tue, 28 Jun 1994 16:41:53 +0500

From: yandros@MIT.EDU
Date: Tue, 28 Jun 1994 16:41:53 +0500
Message-Id: <9406282041.AA04950@infocalypse.MIT.EDU>
To: psv@nada.kth.se
In-Reply-To: <9406280949.AA21934@nada.kth.se> (message from Peter Svanberg on Tue, 28 Jun 1994 11:49:06 +0200)
Subject: Re: Treatment of trailing slash after directory name


Given partial URI

d

should expansion of it be treated treated differently
given these context URIs:

(1) magic://a/b/c/
(2) magic://a/b/c

if c is a directory? Before looking at any spec., my
spontaneous answer - being used to Unix - was NO.

MHO: what's a directory? URI's should operate at a higher abstraction
level than `unix filesystem', and `/' indicates a `logical path
component' seperator (although this calls into question (yet again)
the special meaning of `/' and `?' in URIs). I agree with lynx:
`magic://a/b/c/' is a `logical path' and `magic://a/b/c' is a an item
in logical path `a/b/'.

The main reason I decided to speak up, (no, it wasn't just to express
my opinion; I'm sure you get enough of those :-) was to ask about the
case I brought up while explaining some of these things to some people
I work with recently:

Given partial URI:

/foo/bar

and base URI:

scheme://baz/quux/quuux

or even:

scheme://baz/quux/quuux/

What should the resulting URI be? Put another way, is there an
`anchor' for the logical path, and if so, where is `the root'?

Should the above example be:

1. scheme://foo/bar
2. scheme://baz/foo/bar
3. scheme://baz/quux/foo/bar
4. scheme://baz/quux/quuux/foo/bar

(obviously the answer to the first point is relevant here, especiall
to differentiate 3 and 4 (and the other variants), but my question
remains. My intuition from what I'd like the WWW case to be like is:

scheme://baz/foo/bar

but I suppose that, as an abstraction,

scheme://foo/bar

is more `pure' in some sense.

If I've missed this in the existing documentation somewhere, please
forgive me; I'm not completely caught up on all the new RFC drafts I
want to read yet. :-)

chad