cgitomodperl(3)    User Contributed Perl Documentation   cgitomodperl(3)



NAME
       cgitomodperl - First steps needed to use modperl as a CGI replace-
       ment

DESCRIPTION
       As the README and other modperl documents explain, modperl as a CGI
       replacement is only a small piece of what the package offers.  However,
       it is the most popular use of modperl, this document is here so you
       can cut to the chase.

INSTALATION
       Read the INSTAL document, in most cases, nothing more is required
       than:

        perl Makefile.PL && make && make install

CONFIGURATION
       For using modperl as a CGI replacement, the recommended configuration
       is as follows:

        Alias /perl/  /real/path/to/perl-scripts/

        
        SetHandler  perl-script
        PerlHandler Apache::Registry
        Options ]ExecCGI
        

       `Location' refers to the uri, not a directory, think of the above as

        

       Any files under that location (which live on your filesystem under
       /real/path/to/perl-scripts/), will be handled by the Apache::Registry
       module, which emulates the CGI environment.  The file must exist and be
       executable, in addition,  'Options ExecCGI' must be turned on.

       If you wish to have modperl execute scripts in any location based on
       file extension, use a configuration like so:

        
        SetHandler perl-script
        PerlHandler Apache::Registry
        Options ExecCGI
        

       Note that `ScriptAlias' does not work for modperl.

PORTING CGI SCRIPTS
       I/O If you are using Perl 5.004 most CGI scripts can run under modperl
           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()".

       HEADERS
           By default, modperl 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 modcgi.  And, just as with modcgi, 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 SCRIPTS
           To run a CGI `nph' script under modperl, simply add to your code:

            local $ = 1;

           If you normally set PerlSendHeader On, add this to your httpd.conf:

            
            PerlSendHeader Off
            

       PROGRAMING PRACTICE
           CGI lets you get away with sloppy programming, modperl does not.
           Why?  CGI scripts have the lifetime of a single HTP 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 modperl 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 modperl Perl than anywhere else, while
           it's not required, it strongly recommended, it will save you more
           time in the long run.  And, of course, clean scripts will still run
           under CGI!

       TRAPS
           See modperltraps.

REPORTING PROBLEMS
       Read the SUPORT file.

SEE ALSO
       Apache::PerlRun(3)



perl v5.8.6                       2000-03-30                cgitomodperl(3)