|
|
14.02.2006
As the README and other mod_perl documents explain, mod_perl as a CGI replacement is only a small piece of what the package offers. However, it is the most popular use of mod_perl, this document is here so you can cut to the chase. CONFIGURATIONFor using mod_perl as a CGI replacement, the recommended configuration is as follows: Alias /perl/ /real/path/to/perl-scripts/ <Location /perl> SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI </Location> `Location' refers to the uri, not a directory, think of the above as <Location
http://www.yourname.com/perl> <Files ~ "\.pl$"> SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI </Files>Note that `ScriptAlias' does _not_ work for mod_perl. PORTING CGI SCRIPTSI/O If you are using Perl 5.004 most CGI scripts can run under mod_perl untouched. If you're using 5.003, Perl's built-in "read()" and "print()" functions do not work as they do under CGI. If you're using CGI.pm, use "$query-"print> instead of plain 'ol "print()".HEADERSBy default, mod_perl does not send any headers by itself, however, you may wish to change this: PerlSendHeader On Now the response line and common headers will be sent as they are by mod_cgi. And, just as with mod_cgi, PerlSendHeader will not send a terminating newline, your script must send that itself, e.g.: print "Content-type: text/html\n\n"; If you're using CGI.pm and 'print $q->header' you do _not_ need "PerlSendHeader On".NPH SCRIPTSTo run a CGI `nph' script under mod_perl, simply add to your code: local $| = 1; If you normally set PerlSendHeader On, add this to your httpd.conf:<Files */nph-*> PerlSendHeader Off </Files> PROGRAMMING PRACTICECGI lets you get away with sloppy programming, mod_perl does not. Why? CGI scripts have the lifetime of a single HTTP request as a separate process. When the request is over, the process goes away and everything is cleaned up for you, e.g. globals variables, open files, etc. Scripts running under mod_perl have a longer lifetime, over several request, different scripts may be in the same process. This means you must clean up after yourself. You've heard: always 'use strict' and C<-w>!!! It's more important under mod_perl Perl than anywhere else, while it's not required, it strongly recom- mended, it will save you more time in the long run. And, of course, clean scripts will still run under CGI!TRAPS See the mod_perl_traps manpage. SEE ALSO Apache::PerlRun(3) ENVIRONMENTUnder CGI the Perl hash "%ENV" is magical in that it inherits environment variables from the parent process and will set them should a process spawn a child. However, with mod_perl we're in the parent process that would normally setup the common environment variables before spawning a CGI process. Therefore, mod_perl must feed these variables to "%ENV" directly. Normally, this does not happen until the response stage of a request when "PerlHandler" is called. If you wish to set variables that will be available before then, such as for a "Per- lAuthenHandler", you may use the "PerlSetEnv" configuration directive:PerlSetEnv SomeKey SomeValue You may also use the "PerlPassEnv" directive to pass an already existing environment variable to Perl's "%ENV": PerlPassEnv SomeKey The Apache::Include module makes it simple to include Apache::Registry scripts with the mod_include perl directive.
Example:
<!--#perl sub="Apache::Include" arg="/perl/ssi.pl" -->
Other ways of mod_perl Server-side Includesuse Apache::Include (); print "Content-type: text/html\n\n"; print "before include\n"; my $uri = "/perl/env.pl"; Apache::Include->virtual($uri); print "after include\n"; Save this script above as ssi.pl -> http://infocopter.homelinux.org/perl/ssi.pl | |||||||||||||
copyright by reto - created with mytexi