On Monday, January 13, 2003, at 02:40  AM, Greg Stein wrote:
I have copied the httpd development mailing list, because this bug was
specifically addressed over a year ago. I know, because I am the person
who brought it to Greg's attention last time too. Mod_dir should not be
redirecting non-GET requests by default.
It is totally fine if it wants to redirect non-GET requests. Roy can explain
the subtle differences between a URL that ends in a slash and one that
doesn't, but the simple fact is that the server should be able to do the
redirect, and the client should be able to handle it. A client that cannot
is considered broken (and deserves 10 lashes :-).

Ah. Here is a simple example. There is a resource on the server that refers
to a directory on the disk; the URL is http://example.com/dir/. If you GET
it, then you get the index.html and there is an HREF in there to
"page.html". If there was no slash on the end of the request URL, then
following the link takes to http://example.com/page.html. Thus, the server
does a redirect to ensure the slash is present, so that relative links take
you to the right place: http://example.com/dir/page.html.

If you ever attempt to refer to the resource, then you should use the URL
that refers to that resource. Whether it is a GET, a PROPFIND, or a COPY.
Thus, the redirection to ensure that you get the slash on the end.
There is a difference between http://example.com/foo and http://example.com/foo/.
The former refers to the actual directory entry, and the latter refers to the
contents of the directory entry. mod_dir does a redirect to the /'d entry
since it is assuming that the client actually intended to get the contents
of the directory. (/me awaits Roy's flamesent clarification)

-aaron



Reply via email to