httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Doug MacEachern)
Subject Re: mod_perl-0.50a2
Date Fri, 10 May 1996 12:48:48 GMT
At 10:59 AM 5/10/96 +0000, wrote:
>> From: (Doug MacEachern)
>> I have a new version of mod_perl together for those who would like to try it
>> out.  There are actually 2 apache modules now: mod_perl and mod_perl_fast.
>> >From the README:
>> ---
>> These are Apache modules that embed a perl interpreter in the HTTP server.  
>> The benefit of this is that we are able to run scripts without going through
>> the expensive (fork/exec/parameter passing/parsing, etc.) CGI interface.  
>> The scripts will run faster and they have direct access to the C API of the
>> server.
>> The current approach of mod_perl is to allocate and construct a new perl
>> interpreter for each request.  The interpreter will then parse and run a
>> perl script and we finally destruct the perl interpreter in order to free
>> memory consumed.  
>> The current approach of mod_perl_fast is to allocate and contruct one perl
>> interpreter when the server starts.  At the same time, load, parse and run
>> one perl script, which may pull in other perl code such as your favorite
>> modules.
>> Then, a subroutine in memory is called to handle each request.
>> The interpreter is destroyed upon restart or shutdown of the server.
>> ----
>> There is more info in the package at:
>> All of this is still in alpha, nothing is set in stone, waiting to hear the
>> good, the bad and the ugly from all of you...
>Have you looked at using the Safe module within mod_perl_fast?

I have not looked closely, but I plan to, and there has been some discussion
about it.  I was thinking about using some of Malcolm Beattie's safecgiperl
work for a mod_perl_safe module.  Or maybe put the hooks into mod_perl
and/or mod_perl_fast to turn Safe(ness) on or off in the server config
files.  There will be mod_perlish applications that should only be
restricted as far as the apache api itself.  At the same time, there will be
applications who should have standard CGI restrictions, and beyond.  The
Safe module will play a part here, it's simply a matter of where.  I hope to
hear from those who have been thinking about this issue...



View raw message