Re: Problem and Solution to svn import

On Sun, Jan 12, 2003 at 07:31:56PM -0800, rbb@rkbloom.net wrote:
>...
> Notice that a 301 request is a permanent redirect, and the reason for this
> redirect is that I requested /foobar, not /foobar/. There are a couple of
> problems with this.
>
> 1) The error message isn't very good.

Yah :-(

> 2) I got this even if I put /foobar/ in my request. I haven't done
> enough research to determine if my shell or the svn client was stripping
> off the trailing slash, but something is. I tend to think it is the
> shell.

I don't think the shell would do that. It could be some canonicalization
happening in the client, or something in Apache. Hard to know offhand.

> 3) This is a DAV resource and an OPTIONS request, thus it shouldn't be
> subject to mod_dir's redirection.

Yes and no. I suspect that you have a "foobar" in your document root. That
has been my experience when something like this happens.

The other thing is to ensure that your Location block doesn't have a
trailing slash. That seems to always act a bit weird.

> The solution, luckily, is simple. Add the following to your Apache config
> file:
>
> BrowserMatch "SVN" redirect-carefully

No way. Lines like that are to handle broken clients. Since we know that the
client can be fixed, then that is the correct approach. The
redirect-carefully should never be used to allow/enable broken behavior.

> This instructs mod_dir to only do the redirect on GET requests. That
> should be mentioned in the docs somewhere.

Nope, cuz it shouldn't be in the docs :-)

> 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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org