mod_dav_svn changing the request filename - interaction with mod_rewrite

Hi,
Revision 1512432 causes a regression when mod_dav_svn is used together with mod_rewrite, which we have done successfully since Subversion 1.5. I have also studied the follow up commits which change the approach somewhat from setting filename to null into a bogus file.

Use case:
Using mod_rewrite we can serve information pages using the "correct" Subversion URL.

Example:
http://svn.example.com/svn/repo/folder/?view=details

This page might be served by PHP or other script which is located elsewhere on the server (say /details/index.php). By using a rewrite with PT flag this page can be displayed without redirecting to a separate URL. It was possible before 1.8.3.

- In 1.8.1 works.
- In 1.8.3 the filename is set to null and we get a 404.
- In 1.8.5 the filename is set to something like 'svn:/pathtorepositories/repo/details/'. Also 404.

The PT flag sends the rewritten URI back through URL mapping. For some reason, the recently introduced hook dav_svn__translate_name is executed despite the rewritten URL being outside of the /svn Location. Consequently the request filename field is modified by mod_dav_svn.

My best guess is that the sequence becomes:
- mod_rewrite gets translate_name hook, changes the URI.
- mod_dav_svn gets translate_name hook, because it was initially expected to handle the request.
- renewed URL mapping finds that mod_dav_svn should not handle, selects another one, e.g. mod_php.
- ...

I did some searching in dev-list for discussions on these changes, but I didn't find much. Any recommended reading?

Perhaps the translate_name hook needs to decline in some additional situations, e.g. when the requested path is actually no longer going to be served by mod_dav_svn.

We have failed to find a workaround for this issue so it is a blocker for us to upgrade our production servers beyond 1.8.1.

Thanks in advance,
Thomas Å.
Received on 2013-12-11 14:19:14 CET