3 ms·

This of course disregards the #1 reason to use mod_python (or mod_perl, mod_ruby, or any other fully-integrated scripting language Apache module): namely, becau

by rcoder 18y ago

This of course disregards the #1 reason to use mod_python (or mod_perl, mod_ruby, or any other fully-integrated scripting language Apache module): namely, because you're not just limited to generating dynamic content. The Apache request-handling chain is much richer than simply passing off incoming requests to a CGI or PHP script. Using mod_{perl,python,ruby,etc.}, you can implement authenticators, URL-rewriting modules, log handlers, output filters, etc., and take advantage of the mature Apache infrastructure for such code. Basically, if you want to be able to slice and dice HTTP requests at every stage of processing, not just the content-generation one, the Apache mod_* add-ons are a pretty powerful tool for doing just that.

hobbs 18y ago
You can get all of that by using mod_rewrite/mod_fastcgi/mod_wsgi to passthrough to a full-blown Python app server running behind the web server as a separate process. All of the other mod_* authentication and authorization hurdles will still be evaluated first.
- rcoder 18y ago
  While it may be possible to get the same level of control over the request lifecycle using mod_rewrite and simple dynamic content generation, it can often be awkward and slow compared to doing the same thing via a full-blown Apache scripting module like mod_python. Case in point: I'm currently working on an application that uses mod_auth_kerb to perform Kerberos password authentication on behalf of users, then fork a background server which has access to that user's Kerberos credentials, and proxy future connections from that user to the dedicated backend. Doing that using mod_rewrite requires using the RewriteMap 'prg:' map type, which introduces a single choke-point in the application: namely, the single script responsible for spawning the backend servers. That script also runs in the one Apache master listener, which means that no other incoming requests will be answered until the rewrite script returns its output. If I were instead using mod_perl (as I suspect I will be, before this moves into production) I would be able to have each Apache child process handle its own forking of backends for requests it was handling.

by rcoder 18y ago

hobbs 18y ago

You can get all of that by using mod_rewrite/mod_fastcgi/mod_wsgi to passthrough to a full-blown Python app server running behind the web server as a separate process. All of the other mod_* authentication and authorization hurdles will still be evaluated first.

rcoder 18y ago
While it may be possible to get the same level of control over the request lifecycle using mod_rewrite and simple dynamic content generation, it can often be awkward and slow compared to doing the same thing via a full-blown Apache scripting module like mod_python. Case in point: I'm currently working on an application that uses mod_auth_kerb to perform Kerberos password authentication on behalf of users, then fork a background server which has access to that user's Kerberos credentials, and proxy future connections from that user to the dedicated backend. Doing that using mod_rewrite requires using the RewriteMap 'prg:' map type, which introduces a single choke-point in the application: namely, the single script responsible for spawning the backend servers. That script also runs in the one Apache master listener, which means that no other incoming requests will be answered until the rewrite script returns its output. If I were instead using mod_perl (as I suspect I will be, before this moves into production) I would be able to have each Apache child process handle its own forking of backends for requests it was handling.