On 12/12/13 6:39 AM, Thomas Åkesson wrote: > I am not very familiar with httpd internals, but I would have expected that > PT flag would cause a completely new round of translate_name and > map_to_storage (i.e. one round with original url and one round with rewritten > url). Have you confirmed that is not the case?
That is confirmed. All PT does is rewrite the URI and then return DECLINED in mod_rewrite's translate_name hook which allows the other translate_name hooks to run (translate_name runs until one hook returns OK, which the core hook usually does), intending to ultimately get to the core one which is the final hook. Subversion is preventing that final hook from running (by returning OK) in order to set our own r->filename. We also set a flag on the request to specify that we should prevent the core map_to_storage() hook from running, which we do by also returning OK. The core map_to_storage() hook has a directory and file walk in it that matches the <Directory> blocks which we want to prevent. The problem here is that I have to do the processing in translate_name and map_to_storage hooks. But I can't be assured that when I ask for the per_dir configuration from httpd for my module for the request that it will be accurate because mod_rewrite has changed r->uri without running a new location walk. The 2nd location walk will ultimately happen but not until after translate_name and map_to_storage are done, which is too late for me to solve the problem we made this change for. Anyone reading this that isn't super familiar with request processing in httpd may want to read this: https://httpd.apache.org/docs/2.4/developer/request.html > We see SVN as a component in a larger context. Svn is the core versioned > storage of our CMS-system, where we provide a number of additional services. > Keeping consistent paths significantly reduces end-user confusion and what > we consider a more RESTful set of URLs. > > I do agree that the namespaces belong to SVN. We use a single parameter to > indicate the "operation/view" and definitely not a single-letter one (we > never touch the paths). A concept similar to property namespaces would be > ideal, e.g. cms-view=details (or x-view=details similar to non-registered URL > prefix). Nod. I understand the motivations. It doesn't seem like an unreasonable thing to allow provided it doesn't create problems for us. The only problem here is with PT. You absolutely can use external redirects. You can also use P (PROXY) to get around this as well, though it'll generate a new request at the new URI (and you'll need to have mod_proxy and mod_proxy_http loaded). E.G. RewriteEngine On RewriteCond %{REQUEST_URI} ^/svn/ RewriteCond %{QUERY_STRING} view RewriteRule (.*) http://127.0.0.1:8081/view.php?path=$1 [P,QSA] The patch I posted in my last email is reasonably safe for all of the included modules with httpd. There are no translate_name hooks registered to the APR_HOOK_LAST bucket (like we are) leaving the only hook that follows us as the core translate_name hook, which doesn't use per_dir configuration. The per_dir config is wiped out before the map_to_storage hook is run, so the end of the translate_name hooks is the end of that patch potentially causing problems. The only place where you may run into problems is other 3rd party modules (including modules written using mod_lua that is included with httpd 2.3.x+). But not very many modules hook translate_name. Of course it would have to be maintained and I'm not convinced we should apply it to our own code. That's the best advice I can give for now.
