httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev <>
Subject Improving The RewriteMap Program Feature
Date Fri, 28 Feb 2014 19:52:43 GMT

The RewriteMap Program feature is potentially very powerful but does not appear to be very
robust. While spending some time playing with it I initially came across the following drawbacks:
1. If the RewriteMap Program stops running for some reason, mod_rewrite does not provide any
fallback mechanism.

2. If the RewriteMap Program does not return extremely quickly it could become a bottleneck
since there is only one instance of it running.

If the RewriteMap Program fails, the code within mod_rewrite returns an empty string rather
than NULL. In my tests this caused /index.htm to be returned as the URL which is not very
useful. I think it makes more sense to handle this situation as a NULL so that the default
key is used as we could then provide a backup method.
     RewriteRule ^/proxy/(.*) ${proxymap:$1|/proxybackup/$1} [P]
     RewriteRule ^/proxybackup/(.*) /proxybackup.php?url=$1 [L]

Looking at the mod_rewrite source code this appears to be a one liner change in lookup_map_program:

     if (i == 4 && !strcasecmp(buf, "NULL")) 

     if ((i == 0) || (i == 4 && !strcasecmp(buf, "NULL"))) {
Is this minor change something that you would consider implementing? 

I am also wondering if it would make sense to also try and re-launch the program within lookup_map_program().
Does anybody have any experience or feedback on trying to launch processes (ie: call a variation
of rewritemap_program_child) while a module is processing a request?

As for working around the potential bottleneck, I think this would be more complicated. One
solution would be to launch a pool of programs and allow incoming requests to be handled by
the first unlocked program that was still running. Does this sound like a sensible approach
and does anybody see any potential drawbacks with this?

View raw message