Configuration tips (and perhaps a small bug?)

(Note: I've rewritten this mail several times during the day, so it's
probably very incoherent. There should still be some valid points herein,
though. ;) Here goes...)

I've been fiddling about all day trying to configure Subversion as a
WebDAV-module in a VirtualHost-configuration on Apache 2.0.50. Ideally, this
was what I wanted:

#A The VirtualHost's URL, http://svn.mydomain.com/, should display a HTML
page (perhaps a guide to the repositories available under the VirtualHost).

#B Several http://svn.mydomain.com/<subdir> URLs, where the <subdir>s are
distinct repositories.

While it's easy to fulfil one of these requirements, getting both right at
the same time proved difficult. One obvious solution is to set up a
<Location> or <Directory> container for each of the subdirectories, but that
is against the principle of writing things only once, not scalable,
redundant, and is just generally a bad thing to do in a config file.

So, instead, I tried this (rather typical) configuration:

<VirtualHost *>
    ServerName svn.mydomain.com
    DocumentRoot /services/http/svn.mydomain.com/html
    <Directory /services/http/svn.mydomain.com/html>
        # Subversion/WebDAV and authorization
        DAV svn
        SVNParentPath /services/subversion
        AuthzSVNAccessFile /usr/local/subversion/etc/permissions.conf

        # Authentication
        Require valid-user
        AuthType Basic
        AuthName "MyDomain Subversion Repository"
        AuthUserFile /usr/local/subversion/etc/users.conf
    </Directory>
</VirtualHost>

Well, actually there are a few more directives than this (like access- and
error-logging), but those aren't important. Anyways - repositories in
subdirectories (#B) then works fine, but typing in only
http://svn.mydomain.com/ in a browser doesn't display the index.html file
(which exists in the DocumentRoot), but instead gives a 403 error and this
error_log entry:
[error] The URI does not contain the name of a repository. [403, #190001]

No luck.

It seems the HTTP GET / request gets forwarded to the mod_dav_svn module.
This happens in spite of my using the SVNParentPath directive - I think it
should be apparent that the root URL never contains a repository itself when
using SVNParentPath. ;) The server isn't an intelligent being, however, and
consequently any HTML content in the DocumentRoot is simply ignored (because
DocumentRoot = DAV root, here).

Is there any way for the mod_dav_svn module to refuse processing requests to
the DAV root when SVNParentPath is used, so that Apache can process the
contents of DocumentRoot normally? I.e. instead of the error message above,
it returns the responsibility to Apache. I'm not an Apache module hacker so
I'm not sure if something like this would be possible, but if the
mod_dav_svn developers thinks it is, then perhaps this is an idea? :)

Thus, generally it seemed that if you want to cater for multiple
repositories by having a SVNParentPath directive inside a <Location /dir>
container (or <Directory /path/to/dir> container), then it's not possible to
serve any web content from the URL that corresponds to /dir (physically:
/path/to/dir).

Perhaps this is why everyone seems to have their DAV directive in a subdir
instead of at the root of their VirtualHost - i.e. use <Location /reposdir>
instead of just <Location />...

However, just before sending this mail (some hours ago) I remembered the
LocationMatch directive. So I set out to write a regexp that matched all
subdirs but not the root itself, so that the DAV module wouldn't be
triggered on the root. This is the general solution:

<LocationMatch "^/[^/]+/">
    ...
</LocationMatch>

But there were some problems with this:

It matches ALL subdirectories, even those that doesn't correspond to an
actual repository. Thus, if you try to reference the images/ subdirectory
from your index.html file in the DocumentRoot, the image request will be
grabbed by the DAV module instead. Obviously no image will be served, and
your error_log will be littered with messages to the effect of "unable to
access repository 'images'".

Even Apache's default aliases /icons (used for indexing) and /error (used
for all kinds of error message) will be affected, so whenever a 404 error
message should have been shown a 500 error shows up instead, and even more
error_log entries telling you that there is no 'error' repository (or
'icons' for that matter).

From here, we have two solutions:
1. Excempt error/, icons/ and all other anticipated subdirectories from the
DAV module parsing, like this:
<LocationMatch "^/(?!error|icons|images)[^/]+/">

2. ...or reverse the logic and match the subdirs that you _know_ are
repositories instead:
<LocationMatch "^/(repos1|repos2|repos3)/">

I ended up with solution#2, even if it means I'll have to manually edit the
Apache config file every time I add a new repository. But hey, I do that
several times a week anyway. ;)

If anyone else finds this useful, I guess their choice of solution depends
on whether they have more non-repository or more repository subdirectories.
If you host 200 different repositories, it'd probably be a better idea to
use solution#1.

And now, something quite different. Well, not really. ;)

While trying out different configurations, I also tried to switch from
"SVNParentPath /services/subversion" to "SVNPath
/services/subversion/subdir". When the configuration otherwise is as I
_first_ listed (i.e. using Directory instead of LocationMatch), entering
http://svn.mydomain.com/ in my browser produces this fatal Apache error:

assertion "is_canonical (path, len)" failed: file
"subversion/libsvn_subr/path.c", line 391
[notice] child pid 1889 exit signal Abort trap (6)

This error appears in the Apache's main error_log, and not the VirtualHost's
error_log, as it seems like the child process Apache spawns to process the
request dies altogether. However, when modifying the configuration again
(slightly) so that it uses <Location /> instead of <Directory
/path/to/documentroot> the problems disappears.

The scope of the Subversion configuration directives (DAV, SVNPath,
SVNParentPath, etc.) is "directory", meaning it _should_ be equally
acceptable to put them in a <Directory> container as in a <Location>
container, right?

In practice, however, it seems a SVNPath directive inside a <Directory>
container means trouble (unless the physical directory doesn't exist, in
which case the <Directory> configuration is invalid, ignored, and you'll get
a 404 error instead). Is this supposed to happen (i.e. I've done a
configuration error) or is it a bug in the mod_dav_svn module?

... *phew* :)

-- 
Martin Lie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org