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.
Received on 2013-12-12 18:10:44 CET