DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35077>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35077 ------- Additional Comments From [EMAIL PROTECTED] 2005-06-03 01:53 ------- 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
