I'm hosting some SVN-repos using mod_dav_svn and am running into
problems when using URLs with spaces.
My approach is simply to have a directory structure of SVN-repos
grouped by customers or some topic and for each of those groups I want
to configure a corresponding URL as entry point into mod_dav_svn. Some
of those groups contain spaces for historical reasons and because I
want to use 1:1 paths in the file system as URLs, those spaces should
be handled by httpd and mod_dav_svn as well.
Have a look at the following config:
> <Location "/svn/Bin/LSG BE-BB">
> DAV svn
> SVNParentPath "/home/ams_svn_repos/Bin/LSG BE-BB"
> SVNListParentPath On
> SVNAdvertiseV2Protocol Off
> AuthzSVNReposRelativeAccessFile authz
Requests to that location are properly forwarded to mod_dav_svn, but
that fails to calculate the ultimate repo to use:
> (2)No such file or directory: [...] Failed to load the mod_authz_svn config: Can't open file '/home/ams_svn_repos/Bin/LSG BE-BB/svn/conf/authz': No such file or directory
> Access denied: - OPTIONS svn:/Bin/LSG BE-BB/GosaPrint/trunk
When I change the location to use an underscore and request that,
> <Location "/svn/Bin/LSG_BE-BB">
> Access denied: - OPTIONS GosaPrint:/trunk
"Access denied" is the correct thing to do in this case, the important
point is that the correct authz-file has been used, the correct repo
extracted from the URL etc.
So the problem is obviously with the space, but when I change the
"Location" of httpd to contain "%20", that doesn't work, because httpd
doesn't match the location at all anymore:
> <Location "/svn/Bin/LSG%20BE-BB">
> Fehler: The server at
> Fehler: '[...]/svn/Bin/LSG%20BE-BB/GosaPrint/trunk'
> Fehler: does not support the HTTP/DAV protocol
If I provide other locations, those get matched instead, like
"/svn/Bin" and mod_dav_svn calculates another wrong repo name. So it's
not that things don't work anymore at all, but only that httpd seems
to really expect a space in the "Location".
And I think that's the problem: The matched location is forwarded
using a space to mod_dav_svn, which tries to calculate the repo name
from the request and that request most likely containes %20 instead of
the space. So calculation simply fails:
> /* The URL space defined by the SVN provider is always a virtual
> space. Construct the path relative to the configured Location
> (root_path). So... the relative location is simply the URL used,
> skipping the root_path.
> Note: mod_dav has canonialized root_path. It will not have a trailing
> slash (unless it is "/").
> Note: given a URI of /something and a root of /some, then it is
> impossible to be here (and end up with "thing"). This is simply
> because we control /some and are dispatched to here for its
> URIs. We do not control /something, so we don't get here. Or,
> if we *do* control /something, then it is for THAT root.
> relative = ap_stripprefix(uri, root_path);
In the above code, "uri" and "root_path" would need to have the same
representation, either both being encoded or decoded, but I guess both
are different. Because of that, the "root_path" is not stripped, which
leads to "svn" from the URL being the first component and hence use
wrongly as repo name to map into "SVNParentPath".
Similar problems with difference in "Location[Match]" vs. URLs of the
request have been discussed in the past already:
But I couldn't find anything simple like using spaces in URLs to
So, does that make sense to you? Has that problem already been
reported in the past and I simply didn't find it? Is this worth
reporting a bug or already fixed in current versions of SVN?
Any workarounds you can think of with being able to keep the space in
Mit freundlichen Grüßen,
Thorsten Schöning E-Mail: Thorsten.Schoening_at_AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Received on 2019-06-14 12:12:22 CEST