httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: over-aggressive redirection in mod_dir
Date Tue, 27 Feb 2001 20:02:52 GMT
From: "Rodent of Unusual Size" <Ken.Coar@Golux.Com>
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 (no trailing slash), the resource
> > (trailing slash) may respond as if the operation
> >  were invoked on it, and should return a content-location header with
> > 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/ 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/ 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.

View raw message