[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: request failed: 301 Moved Permanently

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-09-19 00:18:09 CEST

On Sep 18, 2005, at 23:21, Erik Huelsmann wrote:

> http://subversion.tigris.org/faq.html#http-301-error

As an Apache administrator, I gotta say I'm pretty baffled by what's
being said there:

> For example, if you've exported a repository as <Location /www/
> foo>, but you've also set your DocumentRoot to be /www, then you're
> in trouble. When the request comes in for /www/foo/bar, apache
> doesn't know whether to find a real file named /foo/bar within your
> DocumentRoot, or whether to ask mod_dav_svn to fetch a file /bar
> from the /www/foo repository. Usually the former case wins, and
> hence the "Moved Permanently" error.
>
> The solution is to make sure your repository <Location> does not
> overlap or live within any areas already exported as normal web
> shares.

There are so many things wrong with this entry, I barely know where
to begin. Apache "doesnt't know" what to do and will therefore
"usually" do it this certain way? No, sorry; I don't buy that: Apache
is not a random number generator. Apache will either always do it one
way, or always another, but it won't switch between them on a whim.

To the rest of it, let's try to construct this example the FAQ entry
seems to be talking about.

<VirtualHost *:80>
     ServerName example.com
     DocumentRoot /www
     <Location /www/foo>
         SVNPath /data/svn
         # etc.
     </Location>
     # etc.
</VirtualHost>

This virtual host definition should be absolutely valid. DocumentRoot
refers to filesystem paths on the server's hard disk. Location refers
to URL paths in web space. As the Apache manual goes to some pains to
explain, web-space URLs need not have any correlation with filesystem
paths. So the above virtual host definition would mean that the web
site which is stored on the hard disk at /www is available under the
URL http://example.com/ and that a repository which is on the hard
disk at /data/svn is available under the URL http://example.com/www/
foo. It's unclear to me why anyone would want to hide a repository
under the web-space URL path /www, but that's what the example said,
so that's what we'll do.

I'm particularly unclear on what the FAQ entry is trying to say when
it talks about a request coming in for /www/foo/bar and how Apache
will be confused by this. Is it talking about the web-space URL
http://example.com/www/foo/bar? If so, it should be handled without
issue by the Location directive, and would mean "the directory /bar
in the repository." Were the Location directive not there, it would
map to the filesystem path /www/www/foo/bar. So no problem exists.
Reading on in the paragraph, though, it seems it's actually talking
about a request for http://example.com/foo/bar, which would translate
to the filesystem path /www/foo/bar. This is not a problem at all;
the web-space path /foo/bar does not match the Location directive /
www/foo, so the files in the filesystem at /www/foo/bar are
delivered, and again no problem exists.

I really don't see why the FAQ entry seems to think that DocumentRoot
and Location are somehow related. What you specify in your
DocumentRoot parameter should have no bearing on how you configure
your Location tags. What am I missing? Or, more to the point, what is
this FAQ entry missing? The FAQ entry was written, meaning someone
had a problem at some point, but they certainly didn't have the
problem the FAQ entry describes, since, as I've shown, no problem
exists in that scenario.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 19 00:19:55 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.