when used with a <Location> block, mod_dav extracts the argument to Location and passes it to inside handlers (namely, mod_dav_svn). This works well for Location blocks. However, if a LocationMatch is given with a complex regular expression, the passed path (the raw regexp) is not practically usable, and causes failures when handlers expect this path to be valid. For example, the following configuration causes Subversion to fail in mod_dav_svn because it doesn't strip the root_path handed down by mod_dav, due to it being a regular expression instead of the real matched path: <LocationMatch /svn(?=/[a-z]+)> DAV svn SvnParentPath /var/lib/svn </LocationMatch> mod_dav should do one of two things: - retrieve correct path information at runtime, if this is possible (ie. getting the actual match LocationMatch found, instead of the expression) - offer a configuration directive to override this path with a static value.
Is this really a bug in mod_dav, or just mod_dav_svn's handling of it?
As far as I can see, mod_dav_svn retrieves a root_dir parameter passed down by mod_dav, which is the Location root directory. Then it does no extra processing of this root_dir, and uses it to strip off the irrelevant parts of URIs, specifically to work out what the repository name is, and what part of the URI is an intra-repository path. When the LocationMatch regexp is simple (ie. not actually a regexp at all, just a plain pattern with no extra regexp markup, like <LocationMatch /svn>), mod_dav_svn successfully works out the repository name and everything goes well. However, if the regexp contains regexp markup, mod_dav_svn fails with an error indicating that it didn't strip the root path off the URIs: trying to open a repository which has the name of the Location block directory, ie. 'svn' for /svn/reposname and <LocationMatch /svn(?=/[a-z]+)>. Given the code mod_dav_svn uses to strip the path, if the root_dir isn't a prefix in the full path, nothing is stripped at all. The full, raw regexp isn't a prefix in the actual URI, so nothing gets stripped and mod_dav_svn chokes trying to open the wrong repository name. In the case I gave above, if mod_dav_svn had been given the string actually matched by the regexp, rather than the full raw regexp, it would have resolved to root_dir being /svn (the lookahead assertion doesn't add text to the match), and the processing would have gone through as with <LocationMatch /svn>. That is my rationale for pointing the finger at mod_dav rather than mod_dav_svn: as mod_dav is the one initially receiving the request through the handler, it should imho clean up the information it passes to submodules, especially in cases where there isn't much to gain from passing raw, untreated data. On the other hand, if it is considered interesting to pass a raw URI to mod_dav_svn, with the reasoning that it should then process it itself to remove the excess information (does mod_dav_svn know the request is passed to it through a LocationMatch? I mean, would it have a way of knowing when to apply regex logic?), then there is implementation work needed in mod_dav_svn. Off the top of my head though, I can't think of a good use of passing down regexps to submodules and leave processing of LocationMatch config to them. Now, I haven't looked into this much more than working out quickly where the problem is likely to be by looking through the source code of mod_dav_svn. It may be a problem with the information apache returns to mod_dav (I don't know how this is handled in apache yet, so I'm more or less blind here), or maybe it is mod_dav_svn's task to strip out the excess info mod_dav provides. But hopefully this extra comment will somewhat explain the reasoning of my reporting the bug to be with mod_dav.
This issue perplexed me for quite some time trying to reconfigure our SVN repositories before I realized the problem was simply the use of actual regex in LocationMatch. In spite of this having been reported years ago, it took a lot of googling before I ran into this bug report. It seems from reading this and one other report of the same phenomenon I found (http://svn.haxx.se/users/archive-2004-07/0653.shtml), also from years ago, that the nature of the problem is known. Has this issue just been forgotten, or is it held up because changing this would cause other problems for other DAV-related modules or something? This really seems a problem for SVN setup. Without even basic regex markup like ^ and $, I'm not sure it's possible to allow SVN listing of the repository roots and/or avoid ambiguity in the LocationMatch patterns for multiple repository stanzas. Just wondering where this was or if anyone remembered it. Thanks!
I have this bug, too. My config: Apache 2.2.16, Subversion 1.6.12 <LocationMatch "^/"> DAV svn ... </LocationMatch> The Apache log says then: Invalid URI in request PROPFIND %5E/NameOfRepository/!svn/vcc/somefile HTTP/1.1 The %5E is the "^" char in the LocationMatch. I found a posting with some detailed analysis: http://www.issociate.de/board/index.php?t=msg&th=141306&rid=0 I hope it helps you to fix the problem.
Confirm <LocationMatch "^/(?!external)"> DAV svn SVNParentPath /data/subversion </LocationMatch> <Location /external/ad> DAV svn SVNPath /data/subversion/ad AuthType Basic ... </Location> Result: In some cases we see the regexp symbols in log. 192.168.9.127 - - [14/Oct/2010:09:24:57 +0000] "OPTIONS /ad HTTP/1.1" 200 204 "-" "SVN/1.6.13 (r1002816) neon/0.29.3" 192.168.9.127 - - [14/Oct/2010:09:24:57 +0000] "PROPFIND /ad HTTP/1.1" 207 661 "-" "SVN/1.6.13 (r1002816) neon/0.29.3" 192.168.9.127 - - [14/Oct/2010:09:24:57 +0000] "PROPFIND %5E/(%3F!external)/ad/!svn/vcc/default HTTP/1.1" 400 298 "-" "SVN/1.6.13 (r1002816) neon/0.29.3"
Still the same problem with mod_dav, mod_dav_svn and LocationMatch. <LocationMatch ^/(?:cliq|ops)/> DAV svn SVNParentPath /opt/svn SVNPathAuthz On .... </LocationMatch> This setup works with browsing of the SVN repositories via HTTP browser, but fails with the mentioned above errors about PROPFIND when trying to use Eclipse or any other client, that requires properties from the SVN repository. Please, fix it! Shouldn't be so hard for 5 y.o. bug :)
Trying to guess where the repository part should start will lead to ambiguities with more complex regular expression. I think the only general solution is to add a DAVBaseURL directive which allows the user to specify what he actually meant.
(In reply to comment #7) > Trying to guess where the repository part should start will lead to ambiguities > with more complex regular expression. I think the only general solution is to > add a DAVBaseURL directive which allows the user to specify what he actually > meant. I don't see, how it is related. There is nothing to do with the repository path in that particular case. We have a combination of LocationMatch, mod_dav and mod_dav_svn. The first one is responsible to match the location, which was requested from the server with the given configuration block. And the result of it is binary - either 'yes' or 'no'. and if it is 'yes' - we have very exact path(local part of the URI) that did match it! If it matched something, that wasn't aimed to - well, blame the writer of the regex. But, in any case, as soon as the block matched - we should have exact URI which should be passed to the mod_dav instead of cryptic regular expression. I'm not sure how easy is to implement it, but at least, that what I'd expect, comparing with the behavior in case of Location. There is absolutely nothing that makes this situation specific to the mod_dav_svn. It just consumes what mod_dav passed to it, and in this situation mod_dav passes garbage.
(In reply to comment #8) > The first one is responsible to match the location, which was requested from > the server with the given configuration block. And the result of it is binary - > either 'yes' or 'no'. and if it is 'yes' - we have very exact path(local part > of the URI) that did match it! If it matched something, that wasn't aimed to - > well, blame the writer of the regex. Well, given a few posibilities, like ^/svn/(?:projecta|projectb)/ ^/svn/(?=projecta|projectb)/ ^/svn/(?=projecta/|projectb/) I doubt that many people know pcre well enough to know that they need the third option. And there are other containers which would confuse mod_dav even more, like <FilesMatch> and <If> (in 2.3/2.4). Another problem is that result of the regex match is not available to mod_dav. Mod_dav would probably have to re-do the regexp match to find out which part matched. > There is absolutely nothing that makes this situation specific to the > mod_dav_svn. That is true.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.
I'm working on a patch for this exactly as Stefan suggests above, adding a "DavBasePath" directive which is then used as the root path of the repo. https://github.com/apache/httpd/pull/376 In my testing this fixes the mod_dav_svn case.
Now fixed on trunk via r1911651
Merged in 2.4.58 - see r1912081