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 d...@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.2000...@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.5040...@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?
