Getting Started with mod_perl in 30 Minutes Page 6

The localhost approach will work only if the browser is
running on the same machine as the server. If not–use the real server name for
this test, for example:

  http://your.server.name/perl/mod_perl_rules1.pl

If there is any problem please refer to the error_log file for the
error reports.

Now it’s a time to move your CGI scripts from
/somewhere/cgi-bin directory to /home/httpd/perl/ and
see them running much much faster, when requested from the newly configured
base URL (/perl/). If you were accessing the script as
/cgi-bin/test.pl, it will now be accessed from
/perl/test.pl.

Some of your scripts might not work immediately and will require some minor
tweaking or even a partial rewrite to work properly with mod_perl. Chances are
that if you are not practicing sloppy programming, the scripts will work
without any modifications at all.

If you have a problem with your scripts, a good approach is to replace
Apache::Registry with Apache::PerlRun in
httpd.conf, as the latter can execute really badly written
scripts. Put the following configuration directives instead in httpd.conf
and restart the server:

  PerlModule Apache::PerlRun
  
    SetHandler perl-script
    PerlHandler Apache::PerlRun
    Options ExecCGI
    PerlSendHeader On
    allow from all
  

Now your scripts should work for sure, unless there is something in them
mod_perl doesn’t accept. We will discuss these nuances in future articles.

The “mod_perl rules”
Apache Perl Module

mod_perl is about running both scripts and handlers. Although I have
started to present mod_perl using scripts because it’s easier if you have
written CGI scripts before, the more advanced use of mod_perl is about writing
handlers. But have no fear. As you will see in a moment, writing handlers is
almost as easy as writing scripts.

To create a mod_perl handler module, all I have to do is to wrap the code I
have used for the script into a handler subroutine, add a
statement to return the status to the server when the subroutine has
successfully completed, and append a package declaration at the top of the
code.

Just as with scripts you can use either the CGI API you are probably used
to:

  ModPerl/Rules1.pm
  ----------------
  package ModPerl::Rules1;
  use Apache::Constants qw(:common);
  
  sub handler{
    print "Content-type: text/plainrnrn";
    print "mod_perl rules!n";
    return OK;
  }


 or the Apache Perl API that allows you to interact more intimately with the

Apache core by providing an API unavailable under regular Perl. Of course in

the simple example that I show, using any of the approaches is fine, but when

you need to use the API, this version of the code should be used. 

  ModPerl/Rules2.pm
  ----------------
  package ModPerl::Rules2;
  use Apache::Constants qw(:common);
  
  sub handler{
    my  = shift;
    ->send_http_header('text/plain');
    print "mod_perl rules!n";
    return OK;
  }


 Create a directory called ModPerl under one of the directories

in @INC (e.g. /usr/lib/perl5/site_perl/5.005), and

put Rules1.pm and Rules2.pm into it, the files should

include the code from the above examples. 

 To find out what the @INC directories are, execute: 
  % perl -le 'print join "n", @INC'