On 12/11/13 5:18 AM, Thomas Åkesson wrote:
> 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.
Hmm this is going to be a pain to fix (possibly impossible). Because what
mod_rewrite is doing is really hackish. When you use the PT (PassThrough) flag
mod_rewrite puts passthrough:/my/new/URL into r->filename. Then eventually it
moves it to r->uri, but not until after it goes through our translate_name
hook. So we can't reliably know if the request is going to be served by us or
not by asking for the per_dir config.
If we disable handling requests that have a passthrough filename then if the
passthrough ends up coming back to us (e.g. /svn/repo/b is mapped to
/svn/repo/a) then the request ends up being mapped to a bogus filesystem path.
If we enable it then requests (like in your configuration) that aren't going
to be handled by us end up not getting mapped properly.
The following patch (code stolen from mod_charset_lite) avoids the problem
you're having but due to the above isn't a good solution.
[[[
Index: subversion/mod_dav_svn/mod_dav_svn.c
===================================================================
--- subversion/mod_dav_svn/mod_dav_svn.c (revision 1549924)
+++ subversion/mod_dav_svn/mod_dav_svn.c (working copy)
@@ -1127,6 +1127,15 @@
if (!conf->fs_path && !conf->fs_parent_path)
return DECLINED;
+ /* mod_rewrite indicators */
+ if (r->filename
+ && (!strncmp(r->filename, "redirect:", 9)
+ || !strncmp(r->filename, "gone:", 5)
+ || !strncmp(r->filename, "passthrough:", 12)
+ || !strncmp(r->filename, "forbidden:", 10))) {
+ return DECLINED;
+ }
+
if (dav_svn__is_parentpath_list(r))
{
/* SVNListParentPath is on and the request is for the conf->root_dir,
]]]
None of these use cases are strictly legal. The namespace both path wise and
query argument wise belong to SVN. Overlaying your own paths or query
arguments is always going to be prone to future incompatibilities. You've just
finally been burned.
The right way to do what you've been doing is some other path like (where /view
is not configured to be handled by Subversion):
http://svn.example.com/view/details/repo/folder
or
http://svn.example.com/view/repo/folder?details
I'll see what I can do but I think you may just have to bite the bullet and
change your configuration.
Received on 2013-12-11 19:45:52 CET