Bug 38355 - DSO support for mod_rewrite
DSO support for mod_rewrite
Status: UNCONFIRMED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_rewrite
2.0.52
All All
: P2 enhancement (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
http://homes.tiscover.com/jrief/mod_r...
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-01-23 11:31 UTC by Jacob Rief
Modified: 2010-10-29 04:46 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Rief 2006-01-23 11:31:43 UTC
This feature enhancement for mod_rewrite adds support for an external
rewrite-program which links dynamically to mod_rewrite instead of communicating
through a pipe, such as RewriteMap prg:/path/to/map_program
This feature can be useful in conditions, where external rewrite programs may
hang. And if they hang, all of the httpd-processes which have to consult the
external mapping programm will hang too, causing a denial of service. Using
dso-support for RewriteMap allows to write more complicated and time consuming
mapping-applications, for instance to connect to database-servers and/or to
search objects on Squid-Caches using ICP.
Comment 1 André Malo 2006-01-23 12:05:47 UTC
I don't understand. Since httpd 2.0 it is possible to write regular modules (dso
or static) which extend mod_rewrite. How is that different?
Comment 2 Jacob Rief 2006-01-23 13:32:33 UTC
(In reply to comment #0)
> This feature enhancement for mod_rewrite adds support for an external
> rewrite-program which links dynamically to mod_rewrite instead of communicating
> through a pipe, such as RewriteMap prg:/path/to/map_program
> This feature can be useful in conditions, where external rewrite programs may
> hang. And if they hang, all of the httpd-processes which have to consult the
> external mapping programm will hang too, causing a denial of service. Using
> dso-support for RewriteMap allows to write more complicated and time consuming
> mapping-applications, for instance to connect to database-servers and/or to
> search objects on Squid-Caches using ICP.

(In reply to comment #1)
> I don't understand. Since httpd 2.0 it is possible to write regular modules (dso
> or static) which extend mod_rewrite. How is that different?

(In reply to comment #2)
Using RewriteMap dso:/path/to/module.so is much easier, than writing a full
Apache module. Have a look at the example on the associated webpage. Writing
such modules is just as easy as writing an external program, however without the
restriction such external programs have. The Squid-Cache for instance allows to
spawn more than one external rewrite-program, and pipes the request to the next
idle program. Apache on the other side allows only one such program, which when
busy, blocks all the other Apache-slots requireing a dynamic rewriting. Remember
what is written about the external rewrite program in the 'URL Rewriting Guide'
---
be very careful:
   1. ``Keep it simple, stupid'' (KISS), because if this program hangs it will
hang the Apache server when the rule occurs.
   2. Avoid one common mistake: never do buffered I/O on stdout! This will cause
a deadloop! Hence the ``$|=1'' in the above example...
   3. Use the RewriteLock directive to define a lockfile mod_rewrite can use to
synchronize the communication to the program. By default no such synchronization
takes place.
---
with this modrewrite-dso-patch you can bypass item 1, 2 and 3.
Comment 3 André Malo 2006-01-23 13:57:12 UTC
Hmm, I think, we have a misunderstanding here. I'm NOT talking about external
programs, but ordinary httpd modules, which may or may not be DSOs. You can
write a module, which defines additional rewrite maps (available via int:
specifier) and have the full power of being an apache module (configuration,
hooks, etc). So... I don't see an advantage of building another way of doing the
same -- as a matter of fact, it's basically duplicating code of mod_so ;-)

(By the way, there are APR functions for loading DSOs portably, one should never
use dlopen/dlsym directly in common httpd modules.)
Comment 4 Jacob Rief 2006-01-23 14:51:10 UTC
Ok, but the Apache-documentation (1.3, 2.0 and 2.2) says:
"Internal Function
MapType: int, MapSource: Internal Apache function
Here the source is an internal Apache function. Currently you cannot create your
own, but the following functions already exists:"

The mod_rewrite_dso-patch is written to allow the writing of such an internal
function using an external module. So if this feature is already implemented in
an alternative way, it seems to be a documentation bug.
Comment 5 André Malo 2006-01-23 14:53:45 UTC
Yep, it's clearly missing in the documentation.
Comment 6 Jacob Rief 2006-01-25 09:17:37 UTC
I would like to document this feature, however searching the web did not point
me onto any related document. Is there any working example on how to extend the
internal mapping function with a self-written Apache module?
Comment 7 Jacob Rief 2006-03-03 15:33:37 UTC
Adding a customized
RewriteMap int:mymapper
still is not possible, not even if one writes its own httpd-module. So
unfortunately this is not some missing documentation, it is still a missing
feature. The problem is, that a module-writer would have to register its
customized mapper-function with  'ap_register_rewrite_mapfunc' which however is
not available to other httpd-modules. It might be enough to remove the 'static'
keyword and make the function available via a .h-file to other modules.
Comment 8 jacksonjones 2010-10-29 04:46:20 UTC
we have a misunderstanding here. I'm NOT talking about external
programs, but ordinary httpd modules, which may or may not be DSOs.I don't understand. Since httpd 2.0 it is possible to write regular modules (dso
or static) which extend mod_rewrite. How is that different?This feature enhancement for mod_rewrite adds support for an external
rewrite-program which links dynamically to mod_rewrite instead of communicating
through a pipe.