Re: svn ls http://svn.host.tld/

On Mon, Jul 29, 2002 at 02:49:31PM -0500, Ben Collins-Sussman wrote:
> Alexy Khrabrov <alexy.khrabrov@setup.org> writes:
>...
> > (1) For the failed top-level ls
> >
> > 128.6.178.78 - - [29/Jul/2002:14:36:39 -0400] "PROPFIND /svn HTTP/1.1" 301 301
>
> I can't reproduce your bug. For example,
>
> $ svn ls http://svn.collab.net/repos/svn
>
> works just fine.
>
> The question is why a PROPFIND on /svn is returning a 301 "Moved
> Permanently" error?
>
> I saw something similar to this once when trying to use a dav client
> to access a mod_dav_fs location.
>
> I can only guess that there is something odd with your httpd or
> httpd.conf...

Nope. This is defined Apache behavior. Requesting a collection *without* a
trailing slash will cause a redirect to the same URI *with* the trailing
slash.

The simplest answer is that:

    http://svn.collab.net/repos/svn
and
    http://svn.collab.net/repos/svn/

Are two *different* resources. The latter can have requests applied to it.
The former issues 301 redirects. This is well-defined and acceptable
behavior (and clients that don't deal with it are *broken*). However, there
are two problems:

1) some clients don't handle a 301 on non-GET requests well.
2) svn does not install redirect handlers during our use of Neon. I have
   never looked into how easy/hard that would be, whether it is truly
   needed, etc. Point is: Neon can(?) handle some of the redirect handling
   for us.

(2) is especially important when we want to (when?) be able to allow the
repository administrator to move their repos to a different hostname and/or
URL within the namespace. The old repos should issue a 301, and we should
continue operating from the new repository.

[ this does imply that we need a way for RA to signal the client/WC that URL
  that it is using needs to be rewritten ]

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