httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton" <>
Subject Re: Inclusion of mpm-itk into HEAD
Date Mon, 25 Jun 2007 10:47:03 GMT
On 25/06/07, Steinar H. Gunderson <> wrote:
> On Mon, Jun 25, 2007 at 08:08:03PM +1000, Graham Dumpleton wrote:
> > Or you can use PHP under fastcgi. With fastcgi the code would run in a
> > separate process and you could have any number of processes
> > corresponding to whatever virtual hosts you have. Because it is a
> > separate process it can run from the outset as whatever user you want
> > thus avoiding any danger points where code would be run as root.
> Yes, it is obviously an alternative, but FastCGI has its own sets of quirks,
> and PHP under CGI too (as far as I know; I'm no PHP user).

Quirks such as? Am not asking to dispute that there aren't any, just
asking out of ignorance as to what they are so I can learn something.

> Also, it won't
> help you for anything that runs as a module; say, mod_dav_svn or mod_perl.
> Various solutions to this problem have different tradeoffs -- among them
> performance, security, complexity and applicability to different scenarios.
> What mpm-itk gives you is a very simple solution that's one line per vhost
> and works with a _lot_ of different use cases out of the box; I believe that
> has a value in itself. Of course, I'd very much prefer a "real" perchild that
> setuids before accepting the connection and then does connection passing, but
> we're now several years (and at least SoC project) since the release of
> Apache 2.0, and it doesn't really seem to be appearing anytime soon.
> >> Doesn't mod_python load these up-front, so they'd be available before the
> >> fork?
> > No. The only thing which is done before the fork is the initialisation
> > of the Python interpreter. It isn't safe to do anything more than that
> > as the parent process runs as root.
> OK, then performance will suffer in this scenario.

And I think you will have similar problems with mod_perl as well given
that it relies to a degree on preloading and caching of Perl modules
as well.

BTW, for a different take on this whole problem you might have a look
at mod_wsgi ( This only solves the problem for a
specific language, but it provides the choice of running a Python web
application embedded in the Apache child process (like mod_python), or
delegated to a daemon process (like mod_fastcgi). The mod_wsgi code
takes concepts such as process management from mod_cgid and proxying
of requests to the daemon process from mod_cgid and mod_scgi. Where it
is different to solutions like mod_scgi and mod_fastcgi though is that
the daemon process is a fork of the parent process, not a distinct
exec'd process. The daemon process then uses Apache/APR to construct
just enough of the normal Apache connection processing code to fake up
a request_rec and bucket chain, that way the exact same handler code
as would be used in the Apache child can be used.


View raw message