httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject mod_rewrite and mod_dav_svn
Date Thu, 12 Dec 2013 00:10:17 GMT
We've recently made a change to mod_dav_svn to start implementing
translate_name and map_to_storage hooks in order to prevent r->filename from
being set to a bogus path since Subversion is servering content that isn't
actually accessible via the standard file I/O APIs...

You can see the reasoning for that here:
https://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap

However, this has had the side effect of creating problems for people who use
mod_rewrite.  See this email to the dev@subversion.apache.org list for an example:
https://mail-archives.apache.org/mod_mbox/subversion-dev/201312.mbox/%3C76026FDD-FF7C-4C71-84EC-3A73F12B6F34%40simonsoft.se%3E

Ultimately, what's happening here is that mod_rewrite is changing the r->uri
and that results in mod_dav_svn's configuration being inaccurate for what would
actually be served, mod_dav_svn continues to believe it should rewrite the path
and hook the map_to_storage to prevent the ap_core_translate() from running and
thus producing an r->filename based off the configured DocumentRoot and r->uri.

This results in the mod_rewrite modification of r->uri to something mod_dav_svn
doesn't serve to result in a 404.  We could take and ignore translate_name
calls that have been messed with by mod_rewrite like the patch in this email:
https://mail-archives.apache.org/mod_mbox/subversion-dev/201312.mbox/%3C52A8B2BF.2000005@reser.org%3E

The problem here is that mod_rewrite could change the URI to anything,
including a path that mod_dav_svn is responsible for or a path that it isn't.
With that patch in place then rewritten paths that mod_dav_svn does serve are
back to original behavior that we made the change to avoid.

I can work around this by triggering a ap_location_walk() and ap_if_walk() in
mod_dav_svn's translate_name hook before retrieving my configuration as I did
in the patch on this email:
https://mail-archives.apache.org/mod_mbox/subversion-dev/201312.mbox/%3C52A8D7AE.5040706@reser.org%3E

However, I'm messing with httpd internals that I don't think I should be and it
also seems like this fix really belongs in mod_rewrite.  Probably by way of an
API call to update the per_dir_config so the module doesn't have to be kept in
sync with whatever is in ap_process_request_internal().

Before anyone says "but you shouldn't be using the per dir config from a
translate_name hook."  I'll point out that mod_rewrite itself is accessing its
per directory configuration.  Several other modules are accessing per directory
configuration as well (mod_proxy, mod_proxy_express, and mod_log_debug).  I'm
not sure if this presents an issue for them since I haven't spent a lot of time
looking into their behavior.  I can say that they are all hooking
translate_name with APR_HOOK_FIRST and only mod_proxy is configured to always
run after mod_rewrite.

I don't seem to have any better place to put this since I need to prevent the
directory_walk that happens in core_map_to_storage.  The new post_perdir_config
might seem like a good place but it can't prevent a request from being subject
to directory access control.

Thoughts?

Mime
View raw message