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
  <Location /perl>
    SetHandler perl-script
    PerlHandler Apache::PerlRun
    Options ExecCGI
    PerlSendHeader On
    allow from all
  </Location>

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/plain\r\n\r\n";
    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'