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 Å.
