From: "Rodent of Unusual Size" <[EMAIL PROTECTED]>
Sent: Tuesday, February 27, 2001 1:31 PM
> > [RFC2396].
> :
> > There is a standing convention that when a collection is referred to
> > by its name without a trailing slash, the trailing slash is
> > automatically appended. Due to this, a resource may accept a URI
> > without a trailing "/" to point to a collection. In this case it
> > SHOULD return a content-location header in the response pointing to
> > the URI ending with the "/". For example, if a client invokes a
> > method on http://foo.bar/blah (no trailing slash), the resource
> > http://foo.bar/blah/ (trailing slash) may respond as if the operation
> > were invoked on it, and should return a content-location header with
> > http://foo.bar/blah/ in it. In general clients SHOULD use the "/"
> > form of collection names.
>
> So we MAY accept "foo" instead of "foo/", and SHOULD emit a
> content-location field if we do, and Web Folders SHOULD include
> the trailing slash in the first place.
Note that we hork this right now, we simply return the barename in some
cases, such as index.html.en given a request for /docs/index.html or
simply /docs/ if the user turned on multiviews.
By properly returning content-location=/docs/index.html.en
we will provide significant stability for relative paths. The obvious
question, if we request /docs/somescript.pl/foo/bar is; or even worse,
if we request /docs/index.html/foo/bar in the above example, can we
actually return the actual script for relative path parsing, e.g.
content-location=/docs/somescript.pl or content-location=/docs/index.html.en
in those cases?
> Note that this is a convention, however, and not a rule.
> "foo" != "foo/" -- but it MAY be treated as though it were.
Absolutely agreed, this is simply shorthand. So is the multiplicity
between /docs, /docs/, /docs/index.html and /docs/index.html.en
> It is not quite as black&white as I thought it to be. I change
> to +1 for the configurable behaviour with the default being the
> treatment as equivalence, and -0 for forcing that treatment by
> fiat in all cases.
+1 here for adding the conditional behavior, and +1 for setting up the
appropriate BrowserMatch semantics to get around the bogus MS implementation,
and +1 to correct content-location to return the 'proper' server-rooted uri.
