perl-modperl-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sbek...@apache.org
Subject cvs commit: modperl-site/faq mod_perl_api.html mod_perl_api.pod mod_perl_cgi.html mod_perl_cgi.pod mod_perl_faq.html mod_perl_faq.pod
Date Wed, 18 Jul 2001 02:29:28 GMT
sbekman     01/07/17 19:29:28

  Modified:    faq      mod_perl_api.html mod_perl_api.pod
                        mod_perl_cgi.html mod_perl_cgi.pod
                        mod_perl_faq.html mod_perl_faq.pod
  Log:
  syncing faq files
  
  Revision  Changes    Path
  1.3       +117 -166  modperl-site/faq/mod_perl_api.html
  
  Index: mod_perl_api.html
  ===================================================================
  RCS file: /home/cvs/modperl-site/faq/mod_perl_api.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mod_perl_api.html	1998/05/30 20:28:00	1.2
  +++ mod_perl_api.html	2001/07/18 02:29:28	1.3
  @@ -1,133 +1,92 @@
  -    <HTML> 
  -	<HEAD> 
  -	    <TITLE>Mod_perl_api - accessing the Apache API via mod_perl ($Date: 1998/05/30 20:28:00 $)
  +<HTML>
  +<HEAD>
  +<TITLE>Mod_perl_api - accessing the Apache API via mod_perl
  +=======
  +Mod_perl_api - accessing the Apache API via mod_perl ($Date: 2001/07/18 02:29:28 $)
  +>>>>>>> 1.2</TITLE>
  +<LINK REV="made" HREF="mailto:stas@stas.extropia.com">
  +</HEAD>
   
  -</TITLE> 
  -	</HEAD>
  +<BODY>
   
  -	<BODY>
  -
  +<A NAME="__index__"></A>
   <!-- INDEX BEGIN -->
   
   <UL>
   
  -	<LI><A HREF="#NAME">NAME</A>
  -	<LI><A HREF="#DESCRIPTION">DESCRIPTION</A>
  -	<LI><A HREF="#Why_can_t_the_server_find_the_ha">Why can't the server find the handler I wrote?</A>
  +	<LI><A HREF="#name">NAME</A></LI>
  +	<LI><A HREF="#description">DESCRIPTION</A></LI>
  +	<LI><A HREF="#why can't the server find the handler i wrote">Why can't the server find the handler I wrote?</A></LI>
   	<UL>
   
  -		<LI><A HREF="#Did_you_enable_the_required_hook">Did you enable the required hook?</A>
  -		<LI><A HREF="#Is_the_handler_correctly_referen">Is the handler correctly referenced in the configuration?</A>
  +		<LI><A HREF="#did you enable the required hook">Did you enable the required hook?</A></LI>
  +		<LI><A HREF="#is the handler correctly referenced in the configuration">Is the handler correctly referenced in the configuration?</A></LI>
   	</UL>
   
  -	<LI><A HREF="#Where_can_I_find_examples_to_get">Where can I find examples to get me started?</A>
  -	<LI><A HREF="#How_can_I_check_if_mod_perl_is_a">How can I check if mod_perl is available during configuration?</A>
  +	<LI><A HREF="#where can i find examples to get me started">Where can I find examples to get me started?</A></LI>
  +	<LI><A HREF="#how can i check if mod_perl is available during configuration">How can I check if mod_perl is available during configuration?</A></LI>
   </UL>
   <!-- INDEX END -->
   
   <HR>
  -<P>
  -<H1><A NAME="NAME">NAME
  -
  -</A></H1>
  -Mod_perl_api - accessing the Apache API via mod_perl ($Date: 1998/01/19
  -12:35:51 $)
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H1><A NAME="DESCRIPTION">DESCRIPTION
  -
  -</A></H1>
  -This part of the mod_perl FAQ deals with the Apache Application
  -Programmer's Interface and how to access it from perl via mod_perl.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H1><A NAME="Why_can_t_the_server_find_the_ha">Why can't the server find the handler I wrote?
  -
  -</A></H1>
  -<P>
  -<HR>
  -<H2><A NAME="Did_you_enable_the_required_hook">Did you enable the required hook?
  -
  -</A></H2>
  -As described in the mod_perl/INSTALL document, the only callback hook
  -enabled by default is PerlHandler. If you want to intervene at a different
  -stage of request processing you must enable the relevant hook. So to add a
  -special authentication handler, for instance, you would start the
  -installation process with:
  -
  -
  -<P>
  -
  -<PRE>  perl Makefile.PL PERL_AUTHEN=1
  -</PRE>
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Is_the_handler_correctly_referen">Is the handler correctly referenced in the configuration?
  -
  -</A></H2>
  -Apache must be told to load your handler, either as a module with the
  -<CODE>PerlModule</CODE> directive or as a script with <CODE>PerlRequire</CODE>. The handler subroutine will then be available, but you must also specify
  -which requests it should process. This is done by naming it in one of the
  -Perl*Handler directives (PerlInitHandler, PerlTransHandler, etc.). If this
  -directive is put in access.conf outside of any restrictive context, your
  -handler will be called during the given phase of each request processed by
  -the server. You can make it more selective by restricting it to a directory
  -(-hierarchy) in a &lt;Directory ...&gt; section of access.conf or by
  -putting it in a .htaccess file.
  -
  -
  -<P>
  -
  -Here is an example of the directives needed to call a handler during
  -Apache's URI to filename translation phase:
  -
  -
   <P>
  -
  -<PRE>  PerlRequire         /full/path/to/script/Trans.pl
  -  PerlTransHandler   Trans::handler
  +<H1><A NAME="name">NAME</A></H1>
  +<P>&lt;&lt;&lt;&lt;&lt;&lt;&lt; mod_perl_api.pod
  +Mod_perl_api - accessing the Apache API via mod_perl ($Date: 2001/07/18 02:29:28 $)
  +=======
  +Mod_perl_api - accessing the Apache API via mod_perl ($Date: 2001/07/18 02:29:28 $)
  +&gt;&gt;&gt;&gt;&gt;&gt;&gt; 1.2</P>
  +<P>
  +<HR>
  +<H1><A NAME="description">DESCRIPTION</A></H1>
  +<P>This part of the mod_perl FAQ deals with the Apache Application
  +Programmer's Interface and how to access it from perl via mod_perl.</P>
  +<P>
  +<HR>
  +<H1><A NAME="why can't the server find the handler i wrote">Why can't the server find the handler I wrote?</A></H1>
  +<P>
  +<H2><A NAME="did you enable the required hook">Did you enable the required hook?</A></H2>
  +<P>As described in the mod_perl/INSTALL document, the only callback hook
  +enabled by default is PerlHandler.  If you want to intervene at a
  +different stage of request processing you must enable the relevant
  +hook.  So to add a special authentication handler, for instance, you
  +would start the installation process with:</P>
  +<PRE>
  +  perl Makefile.PL PERL_AUTHEN=1</PRE>
  +<P>
  +<H2><A NAME="is the handler correctly referenced in the configuration">Is the handler correctly referenced in the configuration?</A></H2>
  +<P>Apache must be told to load your handler, either as a module with the
  +<CODE>PerlModule</CODE> directive or as a script with <CODE>PerlRequire</CODE>.  The
  +handler subroutine will then be available, but you must also specify
  +which requests it should process.  This is done by naming it in one of
  +the Perl*Handler directives (PerlInitHandler, PerlTransHandler, etc.).
  +If this directive is put in access.conf outside of any restrictive
  +context, your handler will be called during the given phase of each
  +request processed by the server.  You can make it more selective by
  +restricting it to a directory (-hierarchy) in a &lt;Directory ...&gt;
  +section of access.conf or by putting it in a .htaccess file.</P>
  +<P>Here is an example of the directives needed to call a handler during
  +Apache's URI to filename translation phase:</P>
  +<PRE>
  +  PerlRequire         /full/path/to/script/Trans.pl
  +  PerlTransHandler   Trans::handler</PRE>
  +<P>Trans.pl would start with the statement <CODE>Package Trans;</CODE> and define a
  +subroutine called <CODE>handler</CODE>.</P>
  +<P>
  +<HR>
  +<H1><A NAME="where can i find examples to get me started">Where can I find examples to get me started?</A></H1>
  +<P>Check out the Apache-Perl-contrib tarfile at
  +<A HREF="http://perl.apache.org/src/">http://perl.apache.org/src/</A></P>
  +<P>Here is an example from Vivek Khera.  It allows you to filter files
  +through a perl script based on their location.  Rather than having to
  +invoke a CGI script, the user just references the file with a normal
  +URL and it is automagically processed by this code...</P>
  +<PRE>
  +  #! /usr/local/bin/perl
  +  use strict;
   </PRE>
  +<PRE>
   
  -<P>
  -
  -Trans.pl would start with the statement <CODE>Package Trans;</CODE> and define a subroutine called <CODE>handler</CODE>.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H1><A NAME="Where_can_I_find_examples_to_get">Where can I find examples to get me started?
  -
  -</A></H1>
  -Check out the Apache-Perl-contrib tarfile at <A
  -HREF="http://perl.apache.org/src/">http://perl.apache.org/src/</A>
  -
  -
  -<P>
  -
  -Here is an example from Vivek Khera. It allows you to filter files through
  -a perl script based on their location. Rather than having to invoke a CGI
  -script, the user just references the file with a normal URL and it is
  -automagically processed by this code...
  -
  -
  -<P>
  -
  -<PRE>  #! /usr/local/bin/perl
  -  use strict;
  -  
     # filter a file before returning it to the web client
     # tell Apache to use the PerlHandler FileFilter on file which need
     # filtering in the htaccess file:
  @@ -135,31 +94,36 @@
     # &lt;Files *.baz&gt;
     #  SetHandler  perl-script
     #  PerlHandler FileFilter
  -  # &lt;/Files&gt;
  -  
  -  package FileFilter;
  -  
  -  use Apache::Constants ':common';
  -  
  +  # &lt;/Files&gt;</PRE>
  +<PRE>
  +
  +  package FileFilter;</PRE>
  +<PRE>
  +
  +  use Apache::Constants ':common';</PRE>
  +<PRE>
  +
     # find out the file name, then write it out with our header attached
     sub handler {
  -    my $r = shift;
  -  
  -    my $fileName = $r-&gt;filename;
  -  
  -    open(F,$fileName) or return NOT_FOUND; # file not found
  -  
  +    my $r = shift;</PRE>
  +<PRE>
  +
  +    my $fileName = $r-&gt;filename;</PRE>
  +<PRE>
  +
  +    open(F,$fileName) or return NOT_FOUND; # file not found</PRE>
  +<PRE>
  +
       $r-&gt;content_type('text/html');
  -    $r-&gt;no_cache(1);              # don't be caching my dynamic documents!
  -  
  -    $r-&gt;send_http_header;
  -  
  -    $r-&gt;print(&quot;&lt;HEAD&gt;&lt;TITLE&gt;This is my personal header!&lt;/TITLE&gt;&lt;/HEAD&gt;&lt;BODY&gt;&quot;);
  -</PRE>
  +    $r-&gt;no_cache(1);              # don't be caching my dynamic documents!</PRE>
  +<PRE>
   
  -<P>
  +    $r-&gt;send_http_header;</PRE>
  +<PRE>
   
  -<PRE>    # Now copy the file to the client.  If you do not need to make any
  +    $r-&gt;print(&quot;&lt;HEAD&gt;&lt;TITLE&gt;This is my personal header!&lt;/TITLE&gt;&lt;/HEAD&gt;&lt;BODY&gt;&quot;);</PRE>
  +<PRE>
  +    # Now copy the file to the client.  If you do not need to make any
       # changes you can copy it verbatim with the single statement
       #    $r-&gt;send_fd(\*F);
       # Otherwise, loop over each line...
  @@ -168,47 +132,34 @@
         $r-&gt;print ($_);
       }
       close(F);
  -  
  -    $r-&gt;print(&quot;&lt;HR&gt;Document created: &quot;, scalar localtime time);
  -    $r-&gt;print(&quot;&lt;/BODY&gt;&quot;);
  -  
  -    OK;
  -  }
  -  
  -  1;
   </PRE>
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H1><A NAME="How_can_I_check_if_mod_perl_is_a">How can I check if mod_perl is available during configuration?
  -
  -</A></H1>
  -Ralf Engelschall writes:
  -
  +<PRE>
   
  -<P>
  -
  -When you compiled one httpd with and the other without mod_perl, then you
  -can simply use &lt;IfModule mod_perl.c&gt;...&lt;/IfModule&gt; to surround
  -the stuff for the httpd compiled with mod_perl. The other then ignores
  -these lines. Example:
  +    $r-&gt;print(&quot;&lt;HR&gt;Document created: &quot;, scalar localtime time);
  +    $r-&gt;print(&quot;&lt;/BODY&gt;&quot;);</PRE>
  +<PRE>
   
  +    OK;
  +  }</PRE>
  +<PRE>
   
  +  1;</PRE>
   <P>
  -
  -<PRE>  &lt;IfModule mod_perl.c&gt;
  +<HR>
  +<H1><A NAME="how can i check if mod_perl is available during configuration">How can I check if mod_perl is available during configuration?</A></H1>
  +<P>Ralf Engelschall writes:</P>
  +<P>When you compiled one httpd with and the other without mod_perl, then
  +you can simply use &lt;IfModule mod_perl.c&gt;...&lt;/IfModule&gt; to surround the
  +stuff for the httpd compiled with mod_perl. The other then ignores
  +these lines. Example:</P>
  +<PRE>
  +  &lt;IfModule mod_perl.c&gt;
     ...stuff for httpd w/ mod_perl...
     &lt;/IfModule&gt;
     &lt;IfModule !mod_perl.c&gt;
     ...stuff for httpd w/o mod_perl...
  -  &lt;/IfModule&gt;
  -</PRE>
  -
  -<P>
  +  &lt;/IfModule&gt;</PRE>
   
  -</DL>
  -    </BODY>
  +</BODY>
   
  -    </HTML>
  +</HTML>
  
  
  
  1.5       +5 -55     modperl-site/faq/mod_perl_api.pod
  
  Index: mod_perl_api.pod
  ===================================================================
  RCS file: /home/cvs/modperl-site/faq/mod_perl_api.pod,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- mod_perl_api.pod	2000/03/05 11:58:42	1.4
  +++ mod_perl_api.pod	2001/07/18 02:29:28	1.5
  @@ -1,6 +1,10 @@
   =head1 NAME
   
  -Mod_perl_api - accessing the Apache API via mod_perl ($Date: 2000/03/05 11:58:42 $)
  +<<<<<<< mod_perl_api.pod
  +Mod_perl_api - accessing the Apache API via mod_perl ($Date: 2001/07/18 02:29:28 $)
  +=======
  +Mod_perl_api - accessing the Apache API via mod_perl ($Date: 2001/07/18 02:29:28 $)
  +>>>>>>> 1.2
   
   =head1 DESCRIPTION
   
  @@ -115,57 +119,3 @@
     <IfModule !mod_perl.c>
     ...stuff for httpd w/o mod_perl...
     </IfModule>
  -
  -=head1 How can I terminate a chain of handlers?
  -
  -During each phase of request processing, apache calls handlers which
  -have registered an interest in looking at and possibly handling the
  -request.  In some phases it makes sense to let all of the handlers
  -have a chance to look at the request.  In other phases the first
  -handler to return "OK" terminates that phase (see the Apache
  -documentation, /manual/misc/API.html).
  -
  -If you define more than one PerlHandler for a phase, they are placed
  -on a stack and all of the handlers on the stack are called
  -sequentially by mod_perl, as long as they return "DECLINED" or "OK".
  -Apache sees the return code from the final handler and reacts to it.
  -If a handler wants to terminate the chain and ensure that no other
  -handler is called after it, it should set the corresponding stack to
  -undef.  For instance, when a TransHandler has set $r->filename, it
  -should terminate with
  -
  -  $r->set_handlers(PerlTransHandler => undef);
  -  return OK;
  -
  -=head1 Why can't my handler see an environment variable that I set in httpd.conf?
  -
  -The configuration directives SetEnv and PassEnv are handled by
  -apache's mod_env during the fixup stage, so mod_perl handlers that run
  -prior to the fixup-stage don't see variables set with them.  You can
  -use PerlSetEnv/PerlPassEnv instead - they are processed as soon as
  -possible during a request.
  -
  -=head1 Why does the server hang when I try to read a FORM?
  -
  -The C<$r-E<gt>content> method reads C<application/x-www-form-urlencoded>
  -data directly from the client and it does not keep a copy, so if you
  -(or another handler) call it again, the server will hang.  One way of
  -avoiding this, if you do not have full control of all the handlers
  -involved, is to convert the request from POST to GET in the first
  -handler that reads the content:
  -
  -    use Apache::Constants qw(M_GET);
  -    
  -    sub My::Test::handler {
  -    	my $r = shift;
  -    
  -    	if ($r->method eq 'POST') { 
  -    	   my $content = $r->content;
  -    	   # ...
  -    	   #make sure nobody else tries to read POST data now that we have
  -    	   $r->method('GET');
  -    	   $r->method_number(M_GET);
  -    	   $r->headers_in->unset('Content-length');
  -    	}
  -        # ...
  -    }
  
  
  
  1.3       +158 -329  modperl-site/faq/mod_perl_cgi.html
  
  Index: mod_perl_cgi.html
  ===================================================================
  RCS file: /home/cvs/modperl-site/faq/mod_perl_cgi.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mod_perl_cgi.html	1998/05/30 20:28:00	1.2
  +++ mod_perl_cgi.html	2001/07/18 02:29:28	1.3
  @@ -1,263 +1,150 @@
  -    <HTML> 
  -	<HEAD> 
  -	    <TITLE>Mod_perl_cgi - running CGI scripts under mod_perl ($Date: 1998/05/30 20:28:00 $)
  +<HTML>
  +<HEAD>
  +<TITLE>Mod_perl_cgi - running CGI scripts under mod_perl</TITLE>
  +<LINK REV="made" HREF="mailto:stas@stas.extropia.com">
  +</HEAD>
   
  -</TITLE> 
  -	</HEAD>
  +<BODY>
   
  -	<BODY>
  -
  +<A NAME="__index__"></A>
   <!-- INDEX BEGIN -->
   
   <UL>
   
  -	<LI><A HREF="#NAME">NAME</A>
  -	<LI><A HREF="#DESCRIPTION">DESCRIPTION</A>
  -	<LI><A HREF="#Why_doesn_t_my_CGI_script_work_a">Why doesn't my CGI script work at all under mod_perl?</A>
  +	<LI><A HREF="#name">NAME</A></LI>
  +	<LI><A HREF="#description">DESCRIPTION</A></LI>
  +	<LI><A HREF="#why doesn't my cgi script work at all under mod_perl">Why doesn't my CGI script work at all under mod_perl?</A></LI>
   	<UL>
   
  -		<LI><A HREF="#File_not_found">File not found</A>
  -		<LI><A HREF="#Forbidden">Forbidden</A>
  -		<LI><A HREF="#Internal_Server_Error">Internal Server Error</A>
  +		<LI><A HREF="#file not found">File not found</A></LI>
  +		<LI><A HREF="#forbidden">Forbidden</A></LI>
  +		<LI><A HREF="#internal server error">Internal Server Error</A></LI>
   	</UL>
   
  -	<LI><A HREF="#My_CGI_script_behaves_strangely_">My CGI script behaves strangely under mod_perl.  Why?</A>
  +	<LI><A HREF="#my cgi script behaves strangely under mod_perl. why">My CGI script behaves strangely under mod_perl.  Why?</A></LI>
   	<UL>
   
  -		<LI><A HREF="#The_server_terminates_after_proc">The server terminates after processing the first request</A>
  -		<LI><A HREF="#Variables_retain_their_value_fro">Variables retain their value from one request to the next</A>
  -		<LI><A HREF="#Variables_B_still_retain_their_">Variables <STRONG>still</STRONG> retain their value from one request to the next</A>
  -		<LI><A HREF="#Do_I_have_to_rewrite_my_legacy_c">Do I have to rewrite my legacy code for mod_perl?</A>
  +		<LI><A HREF="#the server terminates after processing the first request">The server terminates after processing the first request</A></LI>
  +		<LI><A HREF="#variables retain their value from one request to the next">Variables retain their value from one request to the next</A></LI>
  +		<LI><A HREF="#variables still retain their value from one request to the next">Variables <STRONG>still</STRONG> retain their value from one request to the next</A></LI>
  +		<LI><A HREF="#do i have to rewrite my legacy code for mod_perl">Do I have to rewrite my legacy code for mod_perl?</A></LI>
   	</UL>
   
  -	<LI><A HREF="#How_can_my_script_continue_runni">How can my script continue running after sending the response?</A>
  +	<LI><A HREF="#how can my script continue running after sending the response">How can my script continue running after sending the response?</A></LI>
   </UL>
   <!-- INDEX END -->
   
   <HR>
  -<P>
  -<H1><A NAME="NAME">NAME
  -
  -</A></H1>
  -Mod_perl_cgi - running CGI scripts under mod_perl ($Date: 1998/05/28
  -21:42:40 $)
  -
  -
   <P>
  -
  +<H1><A NAME="name">NAME</A></H1>
  +<P>Mod_perl_cgi - running CGI scripts under mod_perl ($Date: 2001/07/18 02:29:28 $)</P>
   <P>
   <HR>
  -<H1><A NAME="DESCRIPTION">DESCRIPTION
  -
  -</A></H1>
  -This part of the mod_perl FAQ deals with questions surrounding CGI scripts.
  -
  -
  +<H1><A NAME="description">DESCRIPTION</A></H1>
  +<P>This part of the mod_perl FAQ deals with questions surrounding CGI
  +scripts.</P>
   <P>
  -
  -<P>
   <HR>
  -<H1><A NAME="Why_doesn_t_my_CGI_script_work_a">Why doesn't my CGI script work at all under mod_perl?
  -
  -</A></H1>
  -What are the symptoms? Here are some possibilities.
  -
  -
  -<P>
  -
  +<H1><A NAME="why doesn't my cgi script work at all under mod_perl">Why doesn't my CGI script work at all under mod_perl?</A></H1>
  +<P>What are the symptoms?  Here are some possibilities.</P>
   <P>
  -<HR>
  -<H2><A NAME="File_not_found">File not found
  -
  -</A></H2>
  -Have you made the correct entries in Apache's configuration files? You need
  -to add the <CODE>Alias /perl/ ...</CODE> and <CODE>&lt;Location /perl&gt;...</CODE>
  -directives to access.conf as described in mod_perl.pod. And of course the
  +<H2><A NAME="file not found">File not found</A></H2>
  +<P>Have you made the correct entries in Apache's configuration files?  You
  +need to add the <CODE>Alias /perl/ ...</CODE> and <CODE>&lt;Location /perl&gt;...</CODE>
  +directives to access.conf as described in mod_perl.pod.  And of course the
   script must be in the directory specified by the Alias directive and it
  -must be readable and executable by the user that the web server runs as.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Forbidden">Forbidden
  -
  -</A></H2>
  -You don't have permission to access /perl/foo on this server.
  -
  -
  -<P>
  -
  -<PRE>  chmod 755 /path/to/my/mod_perl/scripts
  -  chmod 755 /path/to/my/mod_perl/scripts/foo
  -</PRE>
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Internal_Server_Error">Internal Server Error
  -
  -</A></H2>
  -The script died with an execution error. There should be an error message
  -in the server's error.log saying why. Provided you are using CGI.pm, you
  -can also see what happens by running the script at a shell prompt.
  -
  -
  -<P>
  -
  -If the error.log claims there are syntax errors in your script, but
  -
  -
  -<P>
  -
  -<PRE>  perl -c /path/to/my/mod_perl/scripts/foo
  -</PRE>
  -
  -<P>
  -
  -says it is OK, you have probably used __END__ or __DATA__. Sorry.
  -Mod_perl's Apache::Registry can't deal with that.
  -
  -
  +must be readable and executable by the user that the web server runs as.</P>
   <P>
  -
  +<H2><A NAME="forbidden">Forbidden</A></H2>
  +<P>You don't have permission to access /perl/foo on this server.</P>
  +<PRE>
  +  chmod 755 /path/to/my/mod_perl/scripts
  +  chmod 755 /path/to/my/mod_perl/scripts/foo</PRE>
  +<P>
  +<H2><A NAME="internal server error">Internal Server Error</A></H2>
  +<P>The script died with an execution error.  There should be an error message
  +in the server's error.log saying why.  Provided you are using CGI.pm, you
  +can also see what happens by running the script at a shell prompt.</P>
  +<P>If the error.log claims there are syntax errors in your script,
  +but</P>
  +<PRE>
  +  perl -c /path/to/my/mod_perl/scripts/foo</PRE>
  +<P>says it is OK, you have probably used __END__ or __DATA__.  Sorry.
  +Mod_perl's Apache::Registry can't deal with that.</P>
   <P>
   <HR>
  -<H1><A NAME="My_CGI_script_behaves_strangely_">My CGI script behaves strangely under mod_perl.  Why?
  -
  -</A></H1>
  -Remember that a conventional CGI script always starts up a fresh perl
  +<H1><A NAME="my cgi script behaves strangely under mod_perl. why">My CGI script behaves strangely under mod_perl.  Why?</A></H1>
  +<P>Remember that a conventional CGI script always starts up a fresh perl
   interpreter, whereas a mod_perl script is reused in the same process
  -context many times. This means that certain categories of variables can
  -survive from one invocation of the script to the next. You can make that
  -work to your advantage, but you can also be caught out by it.
  -
  -
  -<P>
  -
  -When diagnosing a problem that might be caused by variable lifetimes,
  -always start the web server in single process mode. Apache normally spawns
  -a number of child processes to handle queries, and they get used in
  -round-robin fashion, which makes test results unpredictable.
  -
  -
  -<P>
  -
  -The command
  -
  -
  -<P>
  -
  -<PRE>  # ./httpd -X
  -</PRE>
  -
  -<P>
  -
  -will start a single-process server with its default configuration. You can
  -specify a different configuration with the -f flag (and thus use a
  -different port number for testing, for instance).
  -
  -
  -<P>
  -
  -Now try executing your script from a browser or with a tool such a wget.
  -Here are some of the effects that you might see.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="The_server_terminates_after_proc">The server terminates after processing the first request
  -
  -</A></H2>
  -Your script is calling the CORE perl <CODE>exit()</CODE> function. That is not a problem in a conventional CGI script, provided that
  -query processing is complete. But you almost certainly don't want to exit
  -in a mod_perl script. It kills the server process that handled the request,
  -meaning that the advantage of using mod_perl to avoid startup overhead is
  -lost.
  -
  -
  -<P>
  -
  -The best way to avoid calling <CODE>exit()</CODE> is to restructure the script so that all execution paths return to a common
  -point at the end of the script. If this seems impractical you can force the
  -same effect by placing a label after the last executable statement and
  -replacing calls to
  -<CODE>exit()</CODE> with <CODE>goto label;</CODE>
  -
  -
  -
  -
  -<P>
  -
  -See also what mod_perl_traps says about <CODE>Apache::exit()</CODE> and the way that Apache::Registry causes it to terminate the script but not
  -the httpd child.
  -
  -
  -<P>
  -
  -There may be exceptional circumstances in which you explicitly want to
  -terminate the httpd child at the end of the current request. In this case <CODE>Apache-&gt;exit(-2)</CODE> should be used.
  -
  -
  -<P>
  -
  +context many times.  This means that certain categories of variables can
  +survive from one invocation of the script to the next.  You can make that
  +work to your advantage, but you can also be caught out by it.</P>
  +<P>When diagnosing a problem that might be caused by variable lifetimes,
  +always start the web server in single process mode.  Apache normally
  +spawns a number of child processes to handle queries, and they get used in
  +round-robin fashion, which makes test results unpredictable.</P>
  +<P>The command</P>
  +<PRE>
  +  # ./httpd -X</PRE>
  +<P>will start a single-process server with its default configuration.  You
  +can specify a different configuration with the -f flag (and thus use a
  +different port number for testing, for instance).</P>
  +<P>Now try executing your script from a browser or with a tool such a wget.
  +Here are some of the effects that you might see.</P>
  +<P>
  +<H2><A NAME="the server terminates after processing the first request">The server terminates after processing the first request</A></H2>
  +<P>Your script is calling the CORE perl <CODE>exit()</CODE> function.  That is not
  +a problem in a conventional CGI script, provided that query processing
  +is complete.  But you almost certainly don't want to exit in a
  +mod_perl script.  It kills the server process that handled the
  +request, meaning that the advantage of using mod_perl to avoid startup
  +overhead is lost.</P>
  +<P>The best way to avoid calling <CODE>exit()</CODE> is to restructure the script so
  +that all execution paths return to a common point at the end of the
  +script.  If this seems impractical you can force the same effect by
  +placing a label after the last executable statement and replacing calls to
  +<CODE>exit()</CODE> with <CODE>goto label;</CODE></P>
  +<P>See also what mod_perl_traps says about <CODE>Apache::exit()</CODE> and the way
  +that Apache::Registry causes it to terminate the script but not the
  +httpd child.</P>
  +<P>There may be exceptional circumstances in which you explicitly want to
  +terminate the httpd child at the end of the current request.  In this
  +case <CODE>Apache-&gt;exit(-2)</CODE> should be used.</P>
   <P>
  -<HR>
  -<H2><A NAME="Variables_retain_their_value_fro">Variables retain their value from one request to the next
  -
  -</A></H2>
  -The so-called sticky query effect happens when the CGI query object, or
  +<H2><A NAME="variables retain their value from one request to the next">Variables retain their value from one request to the next</A></H2>
  +<P>The so-called sticky query effect happens when the CGI query object, or
   another request-specific variable, has a lifetime longer than a single
   execution of your script and does not get reinitialised each time the
  -script is invoked.
  -
  -
  -<P>
  -
  -This does not matter in a conventional CGI script, because the script
  -starts with a clean slate for each new request. But a mod_perl script gets
  -compiled into a subroutine by the Apache::Registry handler and then
  -processes an arbitrary number of requests. To make sure that both you and
  +script is invoked.</P>
  +<P>This does not matter in a conventional CGI script, because the script
  +starts with a clean slate for each new request.  But a mod_perl script
  +gets compiled into a subroutine by the Apache::Registry handler and then
  +processes an arbitrary number of requests.  To make sure that both you and
   the perl interpreter have the same idea about the meaning of your script,
  -make sure it starts like this:
  -
  -
  -<P>
  -
  -<PRE>  #!/usr/bin/perl -w
  +make sure it starts like this:</P>
  +<PRE>
  +  #!/usr/bin/perl -w
  +  use strict;</PRE>
  +<P>It is good for you!  It will make perl point out all variables that you
  +have not explicitly declared.  You can then think about whether they need
  +to be global or if they can be lexical.  Try to declare things lexically,
  +with my().  These variables disappear when the block they are declared in
  +ends, so they don't occupy memory when they are not in use and they also
  +do not need a run-time symbol table entry.</P>
  +<P>Beware, though, of referring to a lexical variable indirectly from within a
  +subroutine.  To quote <EM>perlsub/``Private Variables via my()''</EM>, the
  +variable ``... now becomes unreachable by the outside world, but retains
  +its value between calls to ...''  the subroutine.  You will see classic
  +``sticky query'' symptoms if your code looks like this:</P>
  +<PRE>
  +  #!/usr/bin/perl -w
     use strict;
  -</PRE>
  -
  -<P>
  -
  -It is good for you! It will make perl point out all variables that you have
  -not explicitly declared. You can then think about whether they need to be
  -global or if they can be lexical. Try to declare things lexically, with
  -<CODE>my().</CODE> These variables disappear when the block they are
  -declared in ends, so they don't occupy memory when they are not in use and
  -they also do not need a run-time symbol table entry.
  -
  -
  -<P>
  -
  -Beware, though, of referring to a lexical variable indirectly from within a
  -subroutine. To quote <EM>perlsub</EM>, the variable ``... now becomes unreachable by the outside world, but
  -retains its value between calls to ...'' the subroutine. You will see
  -classic ``sticky query'' symptoms if your code looks like this:
  -
  -
  -<P>
  -
  -<PRE>  #!/usr/bin/perl -w
  -  use strict;
     use CGI;
     my $q = CGI-&gt;new();
     doit();
  -  
  +</PRE>
  +<PRE>
  +
     sub doit {
         print($q-&gt;header(), $q-&gt;start_html());
         print('Value is ', $q-&gt;param('val')) if $q-&gt;param;
  @@ -265,113 +152,55 @@
                   $q-&gt;textfield(-name=&gt;'val', -size=&gt;20), ' ',
                   $q-&gt;submit('enter'), $q-&gt;endform);
         print($q-&gt;end_html());
  -  }
  -</PRE>
  -
  -<P>
  -
  -Because you remembered to put the -w switch on the first line, the error
  -log will tell you that ``Variable <CODE>$q</CODE> will not stay shared''
  -(provided you are using perl5.004 or higher).
  -
  -
  -<P>
  -
  -You must either pass the variable to the subroutine as a parameter,
  -
  -
  -<P>
  -
  -<PRE>  doit($q)
  -</PRE>
  -
  -<P>
  -
  -<PRE>  sub doit {
  +  }</PRE>
  +<P>Because you remembered to put the -w switch on the first line, the error
  +log will tell you that ``Variable $q will not stay shared'' (provided you
  +are using perl5.004 or higher).</P>
  +<P>You must either pass the variable to the subroutine as a parameter,</P>
  +<PRE>
  +  doit($q)</PRE>
  +<PRE>
  +  sub doit {
       my($q) = @_;
  -  ....
  -</PRE>
  -
  -<P>
  -
  -or declare this variable to be global,
  -
  -
  -<P>
  -
  -<PRE>  use vars qw($q);
  -  $q = CGI-&gt;new();
  -</PRE>
  -
  -<P>
  -
  -The reason why Perl works this way is explained in a news posting by Mike
  -Guy that is included with this FAQ (mjtg-news.txt).
  -
  -
  -<P>
  -
  -<a href="mjtg-news.txt">mjtg-news.txt</a>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Variables_B_still_retain_their_">Variables <STRONG>still</STRONG> retain their value from one request to the next
  -
  -</A></H2>
  -CGI.pm must pull some extra tricks when it is being used via
  -Apache::Registry. Versions of CGI.pm before 2.35 did not know this, and
  -Apache::Registry will complain if you try to use an earlier version.
  -
  -
  -<P>
  -
  -CGI.pm detects that it is running under Apache::Registry by looking for an
  -environment variable. This test can fail if <CODE>use CGI</CODE> is evaluated too early, before the environment has been set up. That can
  -happen if you have <CODE>use CGI</CODE> in a script and pull the script in with a <CODE>PerlRequire</CODE> directive in httpd.conf. Replacing <CODE>use CGI</CODE> with
  -<CODE>require CGI</CODE> will fix it.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Do_I_have_to_rewrite_my_legacy_c">Do I have to rewrite my legacy code for mod_perl?
  -
  -</A></H2>
  -If you have CGI code that seems to be fundamentally at odds with mod_perl's
  -``compile once, run many'' environment, you may be find that it will work
  -if run under the module <CODE>Apache::PerlRun</CODE>. See the documentation of that module, which is included with recent
  -versions of mod_perl.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H1><A NAME="How_can_my_script_continue_runni">How can my script continue running after sending the response?
  -
  -</A></H1>
  -If the client submits a form that will take some time to process, you may
  -want to say ``Thanks for submitting the form'' and close the connection,
  -before processing it.
  -
  -
  -<P>
  -
  -You can achieve this by registering the subroutine that processes the form
  -as a cleanup handler:
  -
  -
  -<P>
  -
  -<PRE>  if($ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/) {
  +  ....</PRE>
  +<P>or declare this variable to be global,</P>
  +<PRE>
  +  use vars qw($q);
  +  $q = CGI-&gt;new();</PRE>
  +<P>The reason why Perl works this way is explained in a news posting by
  +Mike Guy that is included with this FAQ (mjtg-news.txt).</P>
  +<a href="mjtg-news.txt">mjtg-news.txt</a><P>
  +<H2><A NAME="variables still retain their value from one request to the next">Variables <STRONG>still</STRONG> retain their value from one request to the next</A></H2>
  +<P>CGI.pm must pull some extra tricks when it is being used via
  +Apache::Registry.  Versions of CGI.pm before 2.35 did not know this,
  +and Apache::Registry will complain if you try to use an earlier
  +version.</P>
  +<P>CGI.pm detects that it is running under Apache::Registry by looking
  +for an environment variable.  This test can fail if <CODE>use CGI</CODE> is
  +evaluated too early, before the environment has been set up.  That can
  +happen if you have <CODE>use CGI</CODE> in a script and pull the script in with
  +a <CODE>PerlRequire</CODE> directive in httpd.conf.  Replacing <CODE>use CGI</CODE> with
  +<CODE>require CGI</CODE> will fix it.</P>
  +<P>
  +<H2><A NAME="do i have to rewrite my legacy code for mod_perl">Do I have to rewrite my legacy code for mod_perl?</A></H2>
  +<P>If you have CGI code that seems to be fundamentally at odds with
  +mod_perl's ``compile once, run many'' environment, you may be find that
  +it will work if run under the module <CODE>Apache::PerlRun</CODE>.  See the
  +documentation of that module, which is included with recent versions
  +of mod_perl.</P>
  +<P>
  +<HR>
  +<H1><A NAME="how can my script continue running after sending the response">How can my script continue running after sending the response?</A></H1>
  +<P>If the client submits a form that will take some time to process, you
  +may want to say ``Thanks for submitting the form'' and close the
  +connection, before processing it.</P>
  +<P>You can achieve this by registering the subroutine that processes the
  +form as a cleanup handler:</P>
  +<PRE>
  +  if($ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/) {
         Apache-&gt;request-&gt;register_cleanup(sub { doProcess($query) });
  -  }
  -</PRE>
  -
  -<P>
  +  }</PRE>
   
  -</DL>
  -    </BODY>
  +</BODY>
   
  -    </HTML>
  +</HTML>
  
  
  
  1.4       +9 -64     modperl-site/faq/mod_perl_cgi.pod
  
  Index: mod_perl_cgi.pod
  ===================================================================
  RCS file: /home/cvs/modperl-site/faq/mod_perl_cgi.pod,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- mod_perl_cgi.pod	2000/03/05 11:58:42	1.3
  +++ mod_perl_cgi.pod	2001/07/18 02:29:28	1.4
  @@ -1,6 +1,6 @@
   =head1 NAME
   
  -Mod_perl_cgi - running CGI scripts under mod_perl ($Date: 2000/03/05 11:58:42 $)
  +Mod_perl_cgi - running CGI scripts under mod_perl ($Date: 2001/07/18 02:29:28 $)
   
   =head1 DESCRIPTION
   
  @@ -40,48 +40,6 @@
   says it is OK, you have probably used __END__ or __DATA__.  Sorry.
   Mod_perl's Apache::Registry can't deal with that.
   
  -=head1 The script runs but the headers are mangled
  -
  -You have a script that works fine under mod_cgi but the browser
  -displays "Content-Type: text/html" or similar headers at the top of
  -the page when it is run under mod_perl.  There are two possible
  -causes.
  -
  -Something, either your script or mod_perl or CGI.pm (if you are using
  -it) has to trigger Apache to send the response header.  This happens
  -when you call the CGI.pm $q->header method or mod_perl's
  -$r->send_http_header.  But if your script just prints out one or more
  -header lines followed by a blank line and the page content, you need
  -to set "PerlSendHeader On" in the configuration for the location of
  -the script.  This tells mod_perl to parse the stuff that the script
  -prints and call $r->send_http_header for you when it sees the blank
  -line.
  -
  -This parsing only happens if PerlSendHeader is on and the header has
  -not been sent yet.  Even so, it is costly and mod_perl makes the
  -assumption that individual headers are not split across print
  -statements, to simplify the parser and avoid having to retain
  -fragments of headers between calls to print().  So the following does
  -not work:
  -
  -   print "Content-type: text/html\n";
  -   print "Set-Cookie: iscookietext\; ";
  -   print "expires=Wednesday, 09-Nov-1999 00:00:00 GMT\; ";
  -   print "path=\/\; domain=\.mmyserver.com\; \n\n";
  -   print "hello";
  -
  -because the Set-Cookie header is split across multiple print's.
  -
  -You need to print each header (or group of headers) in one go,
  -possibly after building it up in a temporary variable.
  -
  -   print "Content-type: text/html\n";
  -   my $cookie = "Set-Cookie: iscookietext; ";
  -   $cookie .= "expires=Wednesday, 09-Nov-1999 00:00:00 GMT; ";
  -   $cookie .= "path=/; domain=.mmyserver.com; \n\n";
  -   print $cookie;
  -   print "hello";
  -
   =head1 My CGI script behaves strangely under mod_perl.  Why?
   
   Remember that a conventional CGI script always starts up a fresh perl
  @@ -98,25 +56,12 @@
   The command
   
     # ./httpd -X
  -
  -will start a single-process server with its default configuration.
  -You can specify a different configuration with the C<-f> flag (and
  -thus use a different port number for testing, for instance).
  -
  -Now try executing your script from a browser.  A non-graphical browser
  -is often much better for diagnosing low-level problems.  Install lynx
  -(http://lynx.browser.org/) if you haven't already got it and use
  -
  -  lynx -mime_header http://localhost/perl/myscript
  -
  -to see the response that the web server produces when it GETs your 
  -script, and
  -
  -  lynx -head -dump http://localhost/perl/myscript
   
  -to see the response to a HEAD request.  The GET and HEAD commands that 
  -come with libwww-perl are similar but slower.
  +will start a single-process server with its default configuration.  You
  +can specify a different configuration with the -f flag (and thus use a
  +different port number for testing, for instance).
   
  +Now try executing your script from a browser or with a tool such a wget.
   Here are some of the effects that you might see.
   
   =head2 The server terminates after processing the first request
  @@ -187,9 +132,9 @@
         print($q->end_html());
     }
   
  -Because you remembered to put the C<-w> switch on the first line, the
  -error log will tell you that "Variable $q will not stay shared"
  -(provided you are using perl5.004 or higher).
  +Because you remembered to put the -w switch on the first line, the error
  +log will tell you that "Variable $q will not stay shared" (provided you
  +are using perl5.004 or higher).
   
   You must either pass the variable to the subroutine as a parameter,
   
  @@ -227,7 +172,7 @@
   =head2 Do I have to rewrite my legacy code for mod_perl?
   
   If you have CGI code that seems to be fundamentally at odds with
  -mod_perl's "compile once, run many" environment, you may find that
  +mod_perl's "compile once, run many" environment, you may be find that
   it will work if run under the module C<Apache::PerlRun>.  See the
   documentation of that module, which is included with recent versions
   of mod_perl.
  
  
  
  1.4       +313 -708  modperl-site/faq/mod_perl_faq.html
  
  Index: mod_perl_faq.html
  ===================================================================
  RCS file: /home/cvs/modperl-site/faq/mod_perl_faq.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- mod_perl_faq.html	1998/07/01 23:18:16	1.3
  +++ mod_perl_faq.html	2001/07/18 02:29:28	1.4
  @@ -1,41 +1,41 @@
  -    <HTML> 
  -	<HEAD> 
  -	    <TITLE>Mod_perl_faq - frequently asked questions about mod_perl ($Date: 1998/07/01 23:18:16 $)
  +<HTML>
  +<HEAD>
  +<TITLE>Mod_perl_faq - frequently asked questions about mod_perl</TITLE>
  +<LINK REV="made" HREF="mailto:stas@stas.extropia.com">
  +</HEAD>
   
  -</TITLE> 
  -	</HEAD>
  +<BODY>
   
  -	<BODY>
  -
  +<A NAME="__index__"></A>
   <!-- INDEX BEGIN -->
   
   <UL>
   
  -	<LI><A HREF="#NAME">NAME</A>
  -	<LI><A HREF="#DESCRIPTION">DESCRIPTION</A>
  -	<LI><A HREF="#QUESTIONS_ANSWERS">QUESTIONS & ANSWERS</A>
  +	<LI><A HREF="#name">NAME</A></LI>
  +	<LI><A HREF="#description">DESCRIPTION</A></LI>
  +	<LI><A HREF="#questions & answers">QUESTIONS &amp; ANSWERS</A></LI>
   	<UL>
   
  -		<LI><A HREF="#What_is_mod_perl_">What is mod_perl?</A>
  -		<LI><A HREF="#Where_can_I_get_mod_perl_">Where can I get mod_perl?</A>
  -		<LI><A HREF="#What_else_do_I_need_">What else do I need?</A>
  -		<LI><A HREF="#How_do_I_install_it_">How do I install it?</A>
  -		<LI><A HREF="#What_documentation_should_I_read">What documentation should I read?</A>
  -		<LI><A HREF="#How_do_I_run_CGI_scripts_under_m">How do I run CGI scripts under mod_perl?</A>
  -		<LI><A HREF="#How_do_I_access_the_Apache_API_f">How do I access the Apache API from mod_perl?</A>
  -		<LI><A HREF="#How_secure_are_mod_perl_scripts_">How secure are mod_perl scripts?</A>
  -		<LI><A HREF="#What_if_my_script_needs_higher_p">What if my script needs higher privileges?</A>
  -		<LI><A HREF="#Why_is_httpd_using_so_much_memor">Why is httpd using so much memory?</A>
  -		<LI><A HREF="#Do_I_have_to_restart_the_server_">Do I have to restart the server when I change my Perl code?</A>
  -		<LI><A HREF="#So_how_do_I_use_mod_perl_in_conj">So how do I use mod_perl in conjunction with ErrorDocument?</A>
  -		<LI><A HREF="#How_can_I_reference_private_libr">How can I reference private library modules?</A>
  -		<LI><A HREF="#How_can_I_pass_arguments_to_a_SS">How can I pass arguments to a SSI script?</A>
  -		<LI><A HREF="#Why_is_image_file_loading_so_slo">Why is image-file loading so slow when testing with httpd -X ?</A>
  -		<LI><A HREF="#What_can_cause_a_subroutine_to_s">What can cause a subroutine to suddenly become undefined?</A>
  -		<LI><A HREF="#What_could_be_causing_sporadic_e">What could be causing sporadic errors "in cleanup"?</A>
  -		<LI><A HREF="#How_can_I_test_that_my_script_is">How can I test that my script is running under mod_perl?</A>
  -		<LI><A HREF="#Where_can_I_get_help_that_I_did_">Where can I get help that I did not find in here?</A>
  -		<LI><A HREF="#Where_do_I_send_suggestions_and_">Where do I send suggestions and corrections concerning this FAQ?</A>
  +		<LI><A HREF="#what is mod_perl">What is mod_perl?</A></LI>
  +		<LI><A HREF="#where can i get mod_perl">Where can I get mod_perl?</A></LI>
  +		<LI><A HREF="#what else do i need">What else do I need?</A></LI>
  +		<LI><A HREF="#how do i install it">How do I install it?</A></LI>
  +		<LI><A HREF="#what documentation should i read">What documentation should I read?</A></LI>
  +		<LI><A HREF="#how do i run cgi scripts under mod_perl">How do I run CGI scripts under mod_perl?</A></LI>
  +		<LI><A HREF="#how do i access the apache api from mod_perl">How do I access the Apache API from mod_perl?</A></LI>
  +		<LI><A HREF="#how secure are mod_perl scripts">How secure are mod_perl scripts?</A></LI>
  +		<LI><A HREF="#what if my script needs higher privileges">What if my script needs higher privileges?</A></LI>
  +		<LI><A HREF="#why is httpd using so much memory">Why is httpd using so much memory?</A></LI>
  +		<LI><A HREF="#do i have to restart the server when i change my perl code">Do I have to restart the server when I change my Perl code?</A></LI>
  +		<LI><A HREF="#so how do i use mod_perl in conjunction with errordocument">So how do I use mod_perl in conjunction with ErrorDocument?</A></LI>
  +		<LI><A HREF="#how can i reference private library modules">How can I reference private library modules?</A></LI>
  +		<LI><A HREF="#how can i pass arguments to a ssi script">How can I pass arguments to a SSI script?</A></LI>
  +		<LI><A HREF="#why is imagefile loading so slow when testing with httpd x ">Why is image-file loading so slow when testing with httpd -X ?</A></LI>
  +		<LI><A HREF="#what can cause a subroutine to suddenly become undefined">What can cause a subroutine to suddenly become undefined?</A></LI>
  +		<LI><A HREF="#what could be causing sporadic errors in cleanup">What could be causing sporadic errors ``in cleanup''?</A></LI>
  +		<LI><A HREF="#how can i test that my script is running under mod_perl">How can I test that my script is running under mod_perl?</A></LI>
  +		<LI><A HREF="#where can i get help that i did not find in here">Where can I get help that I did not find in here?</A></LI>
  +		<LI><A HREF="#where do i send suggestions and corrections concerning this faq">Where do I send suggestions and corrections concerning this FAQ?</A></LI>
   	</UL>
   
   </UL>
  @@ -43,729 +43,334 @@
   
   <HR>
   <P>
  -<H1><A NAME="NAME">NAME
  -
  -</A></H1>
  -Mod_perl_faq - frequently asked questions about mod_perl ($Date: 1998/05/28
  -21:41:19 $)
  -
  -
  +<H1><A NAME="name">NAME</A></H1>
  +<P>Mod_perl_faq - frequently asked questions about mod_perl ($Date: 2001/07/18 02:29:28 $)</P>
   <P>
  -
  -<P>
   <HR>
  -<H1><A NAME="DESCRIPTION">DESCRIPTION
  -
  -</A></H1>
  -Mod_perl allows an Apache Web Server to directly execute perl code. This
  +<H1><A NAME="description">DESCRIPTION</A></H1>
  +<P>Mod_perl allows an Apache Web Server to directly execute perl code.  This
   document is designed to answer questions that arise when designing new
   applications, and converting existing applications, to run in the mod_perl
  -environment.
  -
  -
  -<P>
  -
  +environment.</P>
   <P>
   <HR>
  -<H1><A NAME="QUESTIONS_ANSWERS">QUESTIONS & ANSWERS
  -
  -</A></H1>
  +<H1><A NAME="questions & answers">QUESTIONS &amp; ANSWERS</A></H1>
   <P>
  -<HR>
  -<H2><A NAME="What_is_mod_perl_">What is mod_perl?
  -
  -</A></H2>
  -The Apache/Perl integration project brings together the full power of the
  -Perl programming language and the Apache HTTP server. This is achieved by
  +<H2><A NAME="what is mod_perl">What is mod_perl?</A></H2>
  +<P>The Apache/Perl integration project brings together the full power of the
  +Perl programming language and the Apache HTTP server.  This is achieved by
   linking the Perl runtime library into the server and providing an
  -object-oriented Perl interface to the server's C language API.
  -
  -
  -<P>
  -
  -Mod_perl is a bundle of software. One part of the bundle is designed to be
  -compiled and linked together with Apache and Perl. The remainder is perl
  -code that provides the object-oriented interface to the ``perl-enabled''
  -web server.
  -
  -
  -<P>
  -
  -The primary advantages of mod_perl are power and speed. You have full
  +object-oriented Perl interface to the server's C language API.</P>
  +<P>Mod_perl is a bundle of software.  One part of the bundle is designed to
  +be compiled and linked together with Apache and Perl.  The remainder is
  +perl code that provides the object-oriented interface to the ``perl-enabled''
  +web server.</P>
  +<P>The primary advantages of mod_perl are power and speed.  You have full
   access to the inner-workings of the web server and can intervene at any
  -stage of request-processing. This allows for customized processing of (to
  -name just a few of the phases) URI-&gt;filename translation,
  -authentication, response generation and logging. There is very little
  -run-time overhead. In particular, it is not necessary to start a separate
  -process, as is often done with web-server extensions. The most wide-spread
  -such extension mechanism, the Common Gateway Interface (CGI), can be
  -replaced entirely with perl-code that handles the response generation phase
  -of request processing. Mod_perl includes a general purpose module for this
  +stage of request-processing.  This allows for customized processing of (to
  +name just a few of the phases) URI-&gt;filename translation, authentication,
  +response generation and logging.  There is very little run-time overhead.
  +In particular, it is not necessary to start a separate process, as is
  +often done with web-server extensions.  The most wide-spread such
  +extension mechanism, the Common Gateway Interface (CGI), can be replaced
  +entirely with perl-code that handles the response generation phase of
  +request processing.  Mod_perl includes a general purpose module for this
   purpose (Apache::Registry) that can transparently run existing perl CGI
  -scripts.
  -
  -
  -<P>
  -
  +scripts.</P>
   <P>
  -<HR>
  -<H2><A NAME="Where_can_I_get_mod_perl_">Where can I get mod_perl?
  -
  -</A></H2>
  -Mod_perl can be found at <A
  -HREF="http://www.perl.com/CPAN/modules/by-module/Apache/">http://www.perl.com/CPAN/modules/by-module/Apache/</A>
  -
  -
  -
  +<H2><A NAME="where can i get mod_perl">Where can I get mod_perl?</A></H2>
  +<P>Mod_perl can be found at
  +<A HREF="http://www.perl.com/CPAN/modules/by-module/Apache/">http://www.perl.com/CPAN/modules/by-module/Apache/</A></P>
   <P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="What_else_do_I_need_">What else do I need?
  -
  -</A></H2>
  +<H2><A NAME="what else do i need">What else do I need?</A></H2>
   <DL>
  -<DT><STRONG><A NAME="item_Perl">Perl
  -
  -</A></STRONG><DD>
  -<A
  -HREF="http://www.perl.com/CPAN/src/latest.tar.gz">http://www.perl.com/CPAN/src/latest.tar.gz</A>
  -
  -
  -
  -<P>
  -
  -Win32 users note: at the time of writing, ActiveState's Perl cannot be used
  -with mod_perl, because it is based on an old version of perl
  -(perl-5.003_07, build 316).
  -
  -
  -<P>
  -
  -<DT><STRONG><A NAME="item_Apache">Apache
  -
  -</A></STRONG><DD>
  +<DT><STRONG><A NAME="item_Perl">Perl</A></STRONG><BR>
  +<DD>
  +<A HREF="http://www.perl.com/CPAN/src/latest.tar.gz">http://www.perl.com/CPAN/src/latest.tar.gz</A>
  +<P>Win32 users note: at the time of writing, ActiveState's Perl cannot be
  +used with mod_perl, because it is based on an old version of perl
  +(perl-5.003_07, build 316).</P>
  +<P></P>
  +<DT><STRONG><A NAME="item_Apache">Apache</A></STRONG><BR>
  +<DD>
   <A HREF="http://www.apache.org/dist/">http://www.apache.org/dist/</A>
  -
  -
  -<P>
  -
  -</DL>
  +<P></P></DL>
   <P>
  -<HR>
  -<H2><A NAME="How_do_I_install_it_">How do I install it?
  -
  -</A></H2>
  -Here is the easiest way to proceed. Let's assume you have the latest
  -version of perl (5.004) installed. Unpack the Apache and Mod_perl tarballs
  -next to one another under a common directory: e.g.
  -
  -
  -<P>
  -
  -<PRE>  % cd /usr/local/src
  +<H2><A NAME="how do i install it">How do I install it?</A></H2>
  +<P>Here is the easiest way to proceed.  Let's assume you have the latest
  +version of perl (5.004) installed.  Unpack the Apache and Mod_perl
  +tarballs next to one another under a common directory: e.g.</P>
  +<PRE>
  +  % cd /usr/local/src
     % zcat apache_1.2.0.tar.gz | tar xf -
  -  % zcat mod_perl-0.98_12.tar.gz | tar xf -
  -</PRE>
  -
  -<P>
  -
  -You probably do not need to change anything in the apache configuration
  -before compiling. Only if you want to enable additional non-standard
  -modules do you need to edit apache_1.2.0/src/Configuration. There is no
  +  % zcat mod_perl-0.98_12.tar.gz | tar xf -</PRE>
  +<P>You probably do not need to change anything in the apache configuration
  +before compiling.  Only if you want to enable additional non-standard
  +modules do you need to edit apache_1.2.0/src/Configuration.  There is no
   need to set CC, CFLAGS, etc., because mod_perl will override them with the
  -values that were used to compile your perl.
  -
  -
  -<P>
  -
  -Now go to the mod_perl directory and follow the instructions in the INSTALL
  -file there. If ``make test'' and ``make install'' are successful, you will
  -find the new web server in apache_1.2.0/src/httpd. Move it to a suitable
  -location, make sure it has access to the correct configuration files, and
  -fire it up.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="What_documentation_should_I_read">What documentation should I read?
  -
  -</A></H2>
  -The mod_perl documentation in mod_perl.pod. After you have installed
  -mod_perl you can read it with the command: <CODE>perldoc mod_perl</CODE>.
  -
  -
  -<P>
  -
  -If you are using mod_perl to extend the server functionality, you will need
  -to read <CODE>perldoc Apache</CODE> and the Apache API notes, which can be found in
  -apache_1.2.0/htdocs/manual/misc/API.html.
  -
  -
  -<P>
  -
  -Existing (perl-) CGI scripts should run as-is under mod_perl. There are a
  -number of reasons why they may need to be adjusted, and these are discussed
  -later in this FAQ. If you are developing a new CGI script it is probably
  -best to use CGI.pm. It is part of the standard perl distribution and its
  -documentation can be read with the command: <CODE>perldoc CGI</CODE>.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="How_do_I_run_CGI_scripts_under_m">How do I run CGI scripts under mod_perl?
  -
  -</A></H2>
  -Refer to <A HREF="././mod_perl_cgi.html#">the mod_perl_cgi FAQ</A> for tips on writing and converting CGI scripts for mod_perl.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="How_do_I_access_the_Apache_API_f">How do I access the Apache API from mod_perl?
  -
  -</A></H2>
  -Interfacing with Apache is discussed in <A HREF="././mod_perl_api.html#">the mod_perl_api FAQ</A>.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="How_secure_are_mod_perl_scripts_">How secure are mod_perl scripts?
  -
  -</A></H2>
  -Because mod_perl runs within an httpd child process, it runs with the
  -user-id and group-id specified in the httpd.conf file. This user/group
  -should have the lowest possible privileges. It should only have access to
  -world readable files. Even so, careless scripts can give away information.
  -You would not want your /etc/passwd file to be readable over the net, for
  -instance.
  -
  -
  -<P>
  -
  -If you turn on tainting checks, perl can help you to avoid the pitfalls of
  -using data received from the net. Setting the <CODE>-T</CODE> switch on the first line of the script is not sufficient to enable tainting
  -checks under mod_perl. You have to include the directive <CODE>PerlTaintCheck On</CODE> in the httpd.conf file.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="What_if_my_script_needs_higher_p">What if my script needs higher privileges?
  -
  -</A></H2>
  -You will have to start a new process that runs under a suitable user-id (or
  -group-id). If all requests handled by the script will need the higher
  -privileges, you might as well write it as a suid CGI script. Read the
  -documentation about suEXEC in Apache-1.2.
  -
  -
  -<P>
  -
  -Alternatively, pre-process the request with mod_perl and fork a suid helper
  -process to handle the privileged part of the task.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Why_is_httpd_using_so_much_memor">Why is httpd using so much memory?
  -
  -</A></H2>
  -Read the section on ``Memory Consumption'' in the mod_perl.pod.
  -
  -
  -<P>
  -
  -Make sure that your scripts are not leaking memory. Global variables stay
  -around indefinitely, lexical variables (declared with <CODE>my())</CODE>
  -are destroyed when they go out of scope, provided there are no references
  -to them from outside of that scope.
  -
  -
  -<P>
  -
  -To get information about the modules that have been loaded and their
  -symbol-tables, use the Apache::Status module. It is enabled by adding these
  -lines to a configuration file (e.g. access.conf);
  -
  -
  -<P>
  -
  -<PRE>  &lt;Location /perl-status&gt;
  +values that were used to compile your perl.</P>
  +<P>Now go to the mod_perl directory and follow the instructions in the
  +INSTALL file there.  If ``make test'' and ``make install'' are successful, you
  +will find the new web server in apache_1.2.0/src/httpd.  Move it to a
  +suitable location, make sure it has access to the correct configuration
  +files, and fire it up.</P>
  +<P>
  +<H2><A NAME="what documentation should i read">What documentation should I read?</A></H2>
  +<P>The mod_perl documentation in mod_perl.pod.  After you have installed
  +mod_perl you can read it with the command: <CODE>perldoc mod_perl</CODE>.</P>
  +<P>If you are using mod_perl to extend the server functionality, you will
  +need to read <CODE>perldoc Apache</CODE> and the Apache API notes, which can be
  +found in apache_1.2.0/htdocs/manual/misc/API.html.</P>
  +<P>Existing (perl-) CGI scripts should run as-is under mod_perl.  There are a
  +number of reasons why they may need to be adjusted, and these are
  +discussed later in this FAQ.  If you are developing a new CGI script it is
  +probably best to use CGI.pm.  It is part of the standard perl distribution
  +and its documentation can be read with the command: <CODE>perldoc CGI</CODE>.</P>
  +<P>
  +<H2><A NAME="how do i run cgi scripts under mod_perl">How do I run CGI scripts under mod_perl?</A></H2>
  +<P>Refer to <A HREF="././mod_perl_cgi.html">the mod_perl_cgi FAQ</A> for tips on writing and converting CGI
  +scripts for mod_perl.</P>
  +<P>
  +<H2><A NAME="how do i access the apache api from mod_perl">How do I access the Apache API from mod_perl?</A></H2>
  +<P>Interfacing with Apache is discussed in <A HREF="././mod_perl_api.html">the mod_perl_api FAQ</A>.</P>
  +<P>
  +<H2><A NAME="how secure are mod_perl scripts">How secure are mod_perl scripts?</A></H2>
  +<P>Because mod_perl runs within an httpd child process, it runs with the
  +user-id and group-id specified in the httpd.conf file.  This user/group
  +should have the lowest possible privileges.  It should only have access
  +to world readable files.  Even so, careless scripts can give away
  +information.  You would not want your /etc/passwd file to be readable over
  +the net, for instance.</P>
  +<P>If you turn on tainting checks, perl can help you to avoid the pitfalls of
  +using data received from the net.  Setting the <CODE>-T</CODE> switch on the first line
  +of the script is not sufficient to enable tainting checks under mod_perl.
  +You have to include the directive <CODE>PerlTaintCheck On</CODE> in the httpd.conf
  +file.</P>
  +<P>
  +<H2><A NAME="what if my script needs higher privileges">What if my script needs higher privileges?</A></H2>
  +<P>You will have to start a new process that runs under a suitable user-id
  +(or group-id).  If all requests handled by the script will need the higher
  +privileges, you might as well write it as a suid CGI script.  Read the
  +documentation about suEXEC in Apache-1.2.</P>
  +<P>Alternatively, pre-process the request with mod_perl and fork a suid
  +helper process to handle the privileged part of the task.</P>
  +<P>
  +<H2><A NAME="why is httpd using so much memory">Why is httpd using so much memory?</A></H2>
  +<P>Read the section on ``Memory Consumption'' in the mod_perl.pod.</P>
  +<P>Make sure that your scripts are not leaking memory.  Global variables
  +stay around indefinitely, lexical variables (declared with <CODE>my())</CODE> are
  +destroyed when they go out of scope, provided there are no references
  +to them from outside of that scope.</P>
  +<P>To get information about the modules that have been loaded and their
  +symbol-tables, use the Apache::Status module.  It is enabled by adding
  +these lines to a configuration file (e.g. access.conf);</P>
  +<PRE>
  +  &lt;Location /perl-status&gt;
     SetHandler  perl-script
     PerlHandler Apache::Status
  -  &lt;/Location&gt;
  -</PRE>
  -
  -<P>
  -
  -Then look at the URL <A
  -HREF="http://www.your.host/perl-status">http://www.your.host/perl-status</A>
  -
  -
  -
  -<P>
  -
  -Joel Wagner reports that calling an undefined subroutine in a module can
  -cause a tight loop that consumes all memory. Here is a way to catch such
  -errors. Define an autoload subroutine
  -
  -
  -<P>
  -
  -<PRE>  sub UNIVERSAL::AUTOLOAD {
  +  &lt;/Location&gt;</PRE>
  +<P>Then look at the URL <A HREF="http://www.your.host/perl-status">http://www.your.host/perl-status</A></P>
  +<P>Joel Wagner reports that calling an undefined subroutine in a module
  +can cause a tight loop that consumes all memory.  Here is a way to
  +catch such errors.  Define an autoload subroutine</P>
  +<PRE>
  +  sub UNIVERSAL::AUTOLOAD {
             my $class = shift;
             warn &quot;$class can't `$UNIVERSAL::AUTOLOAD'!\n&quot;;
  -  }
  -</PRE>
  -
  -<P>
  -
  -It will produce a nice error in error_log, giving the line number of the
  -call and the name of the undefined subroutine.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Do_I_have_to_restart_the_server_">Do I have to restart the server when I change my Perl code?
  -
  -</A></H2>
  -Apache::Registry checks the timestamp of scripts that it has loaded and
  -reloads them if they change. This does not happen for other handlers,
  -unless you program it yourself. One way to do this is in a PerlInitHandler.
  -If you define
  -
  -
  -<P>
  -
  -<PRE>  sub MY::init {
  +  }</PRE>
  +<P>It will produce a nice error in error_log, giving the line number of
  +the call and the name of the undefined subroutine.</P>
  +<P>
  +<H2><A NAME="do i have to restart the server when i change my perl code">Do I have to restart the server when I change my Perl code?</A></H2>
  +<P>Apache::Registry checks the timestamp of scripts that it has loaded
  +and reloads them if they change.  This does not happen for other
  +handlers, unless you program it yourself.  One way to do this is in a
  +PerlInitHandler.  If you define</P>
  +<PRE>
  +  sub MY::init {
         delete $INC{&quot;YourModule.pm&quot;};
         require YourModule;
  -  }
  -</PRE>
  -
  +  }</PRE>
  +<P>as an init handler, it will unconditionally reload YourModule at the
  +start of each request, which may be useful while you are developing a
  +new module.  It can be made more efficient by storing the timestamp of
  +the file in a global variable and only reloading when necessary.</P>
   <P>
  -
  -as an init handler, it will unconditionally reload YourModule at the start
  -of each request, which may be useful while you are developing a new module.
  -It can be made more efficient by storing the timestamp of the file in a
  -global variable and only reloading when necessary.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="So_how_do_I_use_mod_perl_in_conj">So how do I use mod_perl in conjunction with ErrorDocument?
  -
  -</A></H2>
  -Andreas Koenig writes:
  -
  -
  -<P>
  -
  +<H2><A NAME="so how do i use mod_perl in conjunction with errordocument">So how do I use mod_perl in conjunction with ErrorDocument?</A></H2>
  +<P>Andreas Koenig writes:</P>
   <UL>
  -<LI><STRONG></STRONG>
  +<LI>
   Set up your testing engine:
  -
  -
  -<P>
  -
  -LWP comes with debugging capabilities that are sometimes better than your
  -browser, sometimes your browser is the better testing device. Make sure you
  -can call lwp-request from the command line and have your browser ready
  -before you start. I find the <CODE>-x</CODE> switch (extended debugging) and the <CODE>-d</CODE> switch (do not display content) most useful.
  -
  -
  -<P>
  -
  -<LI><STRONG></STRONG>
  +<P>LWP comes with debugging capabilities that are sometimes better than
  +your browser, sometimes your browser is the better testing
  +device. Make sure you can call lwp-request from the command line and
  +have your browser ready before you start. I find the <CODE>-x</CODE> switch
  +(extended debugging) and the <CODE>-d</CODE> switch (do not display content) most
  +useful.</P>
  +<P></P>
  +<LI>
   Test your server with
  -
  -
  -<P>
  -
  -<PRE>    lwp-request -xd <A HREF="http://your.server/test/file.not_there">http://your.server/test/file.not_there</A>
  -</PRE>
  -
  -<P>
  -
  -Carefully examine if the status is 404 and if the headers look good.
  -
  -
  -<P>
  -
  -If you try 'lwp-request -es', the HTML output will not be the one you are
  -sending, instead lwp-request will send its own cooked HTML text (as of
  -version libwww-perl-5.09). Check the real text either with the
  -<CODE>-x</CODE> switch or with telnet or your browser.
  -
  -
  -<P>
  -
  -<LI><STRONG></STRONG>
  -Set up your Errordocument configuration in the testing area. I have this in
  -my .htaccess file:
  -
  -
  -<P>
  -
  -<PRE>    ErrorDocument 404 /perl/errors/err404-01
  -</PRE>
  -
  -<P>
  -
  -The /perl/ directory is configured to
  -
  -
  -<P>
  -
  -<PRE>    &lt;Location /perl&gt;
  +<PRE>
  +    lwp-request -xd <A HREF="http://your.server/test/file.not_there">http://your.server/test/file.not_there</A></PRE>
  +<P>Carefully examine if the status is 404 and if the headers look good.</P>
  +<P>If you try 'lwp-request -es', the HTML output will not be the one you
  +are sending, instead lwp-request will send its own cooked HTML text
  +(as of version libwww-perl-5.09). Check the real text either with the
  +<CODE>-x</CODE> switch or with telnet or your browser.</P>
  +<P></P>
  +<LI>
  +Set up your Errordocument configuration in the testing area. I have
  +this in my .htaccess file:
  +<PRE>
  +    ErrorDocument 404 /perl/errors/err404-01</PRE>
  +<P>The /perl/ directory is configured to</P>
  +<PRE>
  +    &lt;Location /perl&gt;
       SetHandler perl-script
       PerlHandler Apache::Registry::handler
       Options ExecCGI
  -    &lt;/Location&gt;
  -</PRE>
  -
  -<P>
  -
  -I have no PerlSendHeader and no PerlNewSendHeader directive in any
  -configuration file.
  -
  -
  -<P>
  -
  -<LI><STRONG></STRONG>
  +    &lt;/Location&gt;</PRE>
  +<P>I have no PerlSendHeader and no PerlNewSendHeader directive in any
  +configuration file.</P>
  +<P></P>
  +<LI>
   Repeat step 2 (Test your server)
  -
  -
  -<P>
  -
  -<LI><STRONG></STRONG>
  -Write your error handler in mod_perl. You have to be prepared that you have
  -to tell both apache *and* the browser the right thing. Basically you have
  -to tell the browser what the error is, but you have to pretend to apache
  -that everything was OK. If you tell apache the error condition, it will
  -handle the situation on its own and add some unwanted stuff to the output
  -that goes to the browser.
  -
  -
  -<P>
  -
  -The following works fine for me:
  -
  -
  -<P>
  -
  -<PRE>    my $r = Apache-&gt;request;
  +<P></P>
  +<LI>
  +Write your error handler in mod_perl. You have to be prepared that you
  +have to tell both apache *and* the browser the right thing. Basically
  +you have to tell the browser what the error is, but you have to
  +pretend to apache that everything was OK. If you tell apache the error
  +condition, it will handle the situation on its own and add some
  +unwanted stuff to the output that goes to the browser.
  +<P>The following works fine for me:</P>
  +<PRE>
  +    my $r = Apache-&gt;request;
       $r-&gt;content_type('text/html; charset=ISO-8859-1');
       $r-&gt;send_http_header;
       $r-&gt;status(200);
  -    ...send other HTML stuff...
  -</PRE>
  -
  -<P>
  -
  -At the time of the send_http_header we have an error condition of type
  -404--this is what gets sent to the browser. After that I set status to 200
  -to silence the apache engine.
  -
  -
  -<P>
  -
  -I was not successful in trying to do the same with CGI.pm, but I didn't try
  -very hard.
  -
  -
  -<P>
  -
  -<LI><STRONG></STRONG>
  +    ...send other HTML stuff...</PRE>
  +<P>At the time of the send_http_header we have an error condition of type
  +404--this is what gets sent to the browser. After that I set status to
  +200 to silence the apache engine.</P>
  +<P>I was not successful in trying to do the same with CGI.pm, but I
  +didn't try very hard.</P>
  +<P></P>
  +<LI>
   Repeat step 2 (Test your server)
  -
  -
  -<P>
  -
  -<LI><STRONG></STRONG>
  +<P></P>
  +<LI>
   The above is tested with mod_perl/0.98 and 0.99
  -
  -
  -<P>
  -
  -<LI><STRONG></STRONG>
  +<P></P>
  +<LI>
   Open questions I could not find documentation for (except RTFS): what
   exactly is PerlSendHeaders and PerlNewSendHeaders. What is the default
   setting for those? How do these cooperate with CGI.pm, Apache.pm,
   Apache::Registry?
  -
  -
  +<P></P></UL>
   <P>
  -
  -</UL>
  -<P>
  -<HR>
  -<H2><A NAME="How_can_I_reference_private_libr">How can I reference private library modules?
  -
  -</A></H2>
  -The best place to put library modules is in the site_perl directory
  +<H2><A NAME="how can i reference private library modules">How can I reference private library modules?</A></H2>
  +<P>The best place to put library modules is in the site_perl directory
   (usually /usr/lib/perl/site_perl), where perl will find them without
  -further ado. Local policy may prevent this, in which case you have to tell
  -the perl interpreter where to find them by adding your private directory to
  -the <CODE>@INC</CODE> array.
  -
  -
  -<P>
  -
  -There are various ways to do this. One way is to add
  -
  -
  -<P>
  -
  -<PRE>  use lib '/my/perl/lib';
  -</PRE>
  -
  -<P>
  -
  -to each script that needs modules from /my/perl/lib.
  -
  -
  -<P>
  -
  -Alternatively, you can arrange for all the modules that might be needed to
  -be loaded when the server starts up. Put a PerlRequire directive into one
  -of the httpd config files that pulls in a small module containing the
  -relevant <CODE>use</CODE>-statements. There is an example of this in <EM>mod_perl_tuning</EM>.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="How_can_I_pass_arguments_to_a_SS">How can I pass arguments to a SSI script?
  -
  -</A></H2>
  -Following the documentation, I have put the following in the html file:
  -
  -
  -<P>
  -
  -<PRE>  &lt;!--#perl sub=&quot;Apache::Include&quot; arg=&quot;/perl/ssi.pl&quot; --&gt;
  -</PRE>
  -
  -<P>
  -
  -I want to send an argument to the ssi.pl script. How?
  -
  -
  -<P>
  -
  -It won't work with Apache::Include. Instead of a script, define a
  -subroutine that's pulled in with PerlRequire or PerlModule, like so:
  -
  -
  -<P>
  -
  -<PRE>  sub My::ssi {
  +further ado.  Local policy may prevent this, in which case you have to
  +tell the perl interpreter where to find them by adding your private
  +directory to the @INC array.</P>
  +<P>There are various ways to do this.  One way is to add</P>
  +<PRE>
  +  use lib '/my/perl/lib';</PRE>
  +<P>to each script that needs modules from /my/perl/lib.</P>
  +<P>Alternatively, you can arrange for all the modules that might be
  +needed to be loaded when the server starts up.  Put a PerlRequire
  +directive into one of the httpd config files that pulls in a small
  +module containing the relevant <CODE>use</CODE>-statements.  There is an example
  +of this in <EM>mod_perl_tuning</EM>.</P>
  +<P>
  +<H2><A NAME="how can i pass arguments to a ssi script">How can I pass arguments to a SSI script?</A></H2>
  +<P>Following the documentation, I have put the following in the html
  +file:</P>
  +<PRE>
  +  &lt;!--#perl sub=&quot;Apache::Include&quot; arg=&quot;/perl/ssi.pl&quot; --&gt;</PRE>
  +<P>I want to send an argument to the ssi.pl script.  How?</P>
  +<P>It won't work with Apache::Include.  Instead of a script, define a
  +subroutine that's pulled in with PerlRequire or PerlModule, like so:</P>
  +<PRE>
  +  sub My::ssi {
        my($r, $one, $two, $three) = @_;
        ...
  -  }
  -</PRE>
  -
  -<P>
  -
  -In the html file:
  -
  -
  -<P>
  -
  -<PRE>  &lt;!--#perl sub=&quot;My::ssi&quot; arg=&quot;one&quot; arg=&quot;two&quot; arg=&quot;three&quot; --&gt;
  -</PRE>
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Why_is_image_file_loading_so_slo">Why is image-file loading so slow when testing with httpd -X ?
  -
  -</A></H2>
  -If you use Netscape while your server is running in single-process mode,
  -the ``KeepAlive'' feature gets in the way. Netscape tries to open multiple
  -connections and keep them open. Because there is only one server process
  -listening, each connection has to time-out before the next succeeds. Turn
  -off KeepAlive in httpd.conf to avoid this effect.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="What_can_cause_a_subroutine_to_s">What can cause a subroutine to suddenly become undefined?
  -
  -</A></H2>
  -If you sometimes see error messages like this:
  -
  -
  -<P>
  -
  -<PRE>  [Thu Sep 11 11:03:06 1997] Undefined subroutine
  +  }</PRE>
  +<P>In the html file:</P>
  +<PRE>
  +  &lt;!--#perl sub=&quot;My::ssi&quot; arg=&quot;one&quot; arg=&quot;two&quot; arg=&quot;three&quot; --&gt;</PRE>
  +<P>
  +<H2><A NAME="why is imagefile loading so slow when testing with httpd x ">Why is image-file loading so slow when testing with httpd -X ?</A></H2>
  +<P>If you use Netscape while your server is running in single-process
  +mode, the ``KeepAlive'' feature gets in the way.  Netscape tries to open
  +multiple connections and keep them open.  Because there is only one
  +server process listening, each connection has to time-out before the
  +next succeeds.  Turn off KeepAlive in httpd.conf to avoid this effect.</P>
  +<P>
  +<H2><A NAME="what can cause a subroutine to suddenly become undefined">What can cause a subroutine to suddenly become undefined?</A></H2>
  +<P>If you sometimes see error messages like this:</P>
  +<PRE>
  +  [Thu Sep 11 11:03:06 1997] Undefined subroutine
     &amp;Apache::ROOT::perl::script1::sub_foo called at
  -  /some/path/perl/script2 line 42.
  -</PRE>
  -
  -<P>
  -
  -despite the fact that script2 normally works just fine, it looks like you
  -have a namespace problem in a library file. If sub_foo is located in a file
  -that is pulled in by 'require' and both script1 and script2 require it, you
  -need to be sure that the file containing sub_foo sets a package name.
  -Otherwise, sub_foo gets defined in the namespace that is active the first
  -time it is required, and the next require is a no-op because that file is
  -already in %INC.
  -
  -
  -<P>
  -
  -The solution is simple, set up your require'd file something along these
  -lines:
  -
  -
  -<P>
  -
  -<PRE>  package SomeName;
  -</PRE>
  -
  -<P>
  -
  -<PRE>  sub sub_foo {...}
  -</PRE>
  -
  -<P>
  -
  -Now, have scripts call SomeName::sub_foo() instead of
  -<CODE>sub_foo().</CODE>
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="What_could_be_causing_sporadic_e">What could be causing sporadic errors "in cleanup"?
  -
  -</A></H2>
  -Some people have seen error messages such as this:
  -
  -
  -<P>
  -
  -<PRE>   [Fri Sep 26 10:50:08 1997]      (in cleanup) no dbproc key in hash
  -   at /usr/lib/perl5/site_perl/Apache/Registry.pm line 119.
  -</PRE>
  -
  -<P>
  -
  -Doug writes:
  -
  -
  -<P>
  -
  -``I have yet to figure out why, but there have been a few arbitrary cases
  -where Perl (in mod_perl) _insists_ on finding and/or calling a DESTROY
  -method for an object. Defining an empty sub DESTROY has been the bandaid
  -for these few cases.''
  -
  -
  -<P>
  -
  -If the specific error message gives you a hint about which object is
  -causing difficulty, put the <CODE>sub DESTROY { }</CODE> in the module that defines that object class.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="How_can_I_test_that_my_script_is">How can I test that my script is running under mod_perl?
  -
  -</A></H2>
  -There are 2 environment variables you can test.
  -
  -
  -<P>
  -
  -<PRE>  exists $ENV{&quot;MOD_PERL&quot;}   # if running under mod_perl
  -</PRE>
  -
  -<P>
  -
  -<PRE>  $ENV{&quot;GATEWAY_INTERFACE&quot;} eq &quot;CGI-Perl/1.1&quot;
  -</PRE>
  -
  -<P>
  -
  -The MOD_PERL variable gets set immediately when the perl interpreter starts
  -up, whereas GATEWAY_INTERFACE may not be set yet when BEGIN blocks are
  -being processed.
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Where_can_I_get_help_that_I_did_">Where can I get help that I did not find in here?
  -
  -</A></H2>
  -There is a mailing-list dedicated to mod_perl. It is archived at <A
  -HREF="http://outside.organic.com/mail-archives/modperl/">http://outside.organic.com/mail-archives/modperl/</A>
  -and at <A
  -HREF="http://forum.swarthmore.edu/epigone/modperl">http://forum.swarthmore.edu/epigone/modperl</A>
  -(which has a search engine) and also at <A
  -HREF="http://www.progressive-comp.com/Lists/?l=apache-modperl&r=1#apache-modperl">http://www.progressive-comp.com/Lists/?l=apache-modperl&r=1#apache-modperl</A>
  -(threaded and indexed).
  -
  -
  -<P>
  -
  -You can subscribe to the list by sending a mail with the line <CODE>subscribe
  -modperl</CODE> to <CODE>majordomo@apache.org</CODE>.
  -
  -
  -<P>
  -
  -The mod_perl homepage <A
  -HREF="http://perl.apache.org/">http://perl.apache.org/</A> has links to
  -other mod_perl resources.
  -
  -
  -<P>
  -
  -The pod source of this FAQ is available at <A
  -HREF="http://www.ping.de/~fdc/mod_perl/mod_perl_faq.tar.gz">http://www.ping.de/~fdc/mod_perl/mod_perl_faq.tar.gz</A>
  -
  -
  -
  -<P>
  -
  -<P>
  -<HR>
  -<H2><A NAME="Where_do_I_send_suggestions_and_">Where do I send suggestions and corrections concerning this FAQ?
  -
  -</A></H2>
  -<A HREF="MAILTO:mailto:fdc@cliwe.ping.de">mailto:fdc@cliwe.ping.de</A>
  -
  +  /some/path/perl/script2 line 42.</PRE>
  +<P>despite the fact that script2 normally works just fine, it looks like
  +you have a namespace problem in a library file.  If sub_foo is located
  +in a file that is pulled in by 'require' and both script1 and script2
  +require it, you need to be sure that the file containing sub_foo sets
  +a package name.  Otherwise, sub_foo gets defined in the namespace that
  +is active the first time it is required, and the next require is a
  +no-op because that file is already in %INC.</P>
  +<P>The solution is simple, set up your require'd file something along
  +these lines:</P>
  +<PRE>
  +  package SomeName;</PRE>
  +<PRE>
  +  sub sub_foo {...}</PRE>
  +<P>Now, have scripts call SomeName::sub_foo() instead of sub_foo().</P>
  +<P>
  +<H2><A NAME="what could be causing sporadic errors in cleanup">What could be causing sporadic errors ``in cleanup''?</A></H2>
  +<P>Some people have seen error messages such as this:</P>
  +<PRE>
  +   [Fri Sep 26 10:50:08 1997]      (in cleanup) no dbproc key in hash
  +   at /usr/lib/perl5/site_perl/Apache/Registry.pm line 119.</PRE>
  +<P>Doug writes:</P>
  +<P>``I have yet to figure out why, but there have been a few arbitrary
  +cases where Perl (in mod_perl) _insists_ on finding and/or calling a
  +DESTROY method for an object.  Defining an empty sub DESTROY has been
  +the bandaid for these few cases.''</P>
  +<P>If the specific error message gives you a hint about which object is
  +causing difficulty, put the <CODE>sub DESTROY { }</CODE> in the module that
  +defines that object class.</P>
  +<P>
  +<H2><A NAME="how can i test that my script is running under mod_perl">How can I test that my script is running under mod_perl?</A></H2>
  +<P>There are 2 environment variables you can test.</P>
  +<PRE>
  +  exists $ENV{&quot;MOD_PERL&quot;}   # if running under mod_perl</PRE>
  +<PRE>
  +  $ENV{&quot;GATEWAY_INTERFACE&quot;} eq &quot;CGI-Perl/1.1&quot;</PRE>
  +<P>The MOD_PERL variable gets set immediately when the perl interpreter
  +starts up, whereas GATEWAY_INTERFACE may not be set yet when BEGIN
  +blocks are being processed.</P>
  +<P>
  +<H2><A NAME="where can i get help that i did not find in here">Where can I get help that I did not find in here?</A></H2>
  +<P>There is a mailing-list dedicated to mod_perl.  It is archived at
  +<A HREF="http://outside.organic.com/mail-archives/modperl/">http://outside.organic.com/mail-archives/modperl/</A> and at
  +<A HREF="http://forum.swarthmore.edu/epigone/modperl">http://forum.swarthmore.edu/epigone/modperl</A> (which has a search
  +engine) and also at
  +<A HREF="http://www.progressive-comp.com/Lists/?l=apache-modperl&r=1#apache-modperl">http://www.progressive-comp.com/Lists/?l=apache-modperl&r=1#apache-modperl</A>
  +(threaded and indexed).</P>
  +<P>You can subscribe to the list by sending a mail with the line <CODE>subscribe
  +modperl</CODE> to <CODE>majordomo@apache.org</CODE>.</P>
  +<P>The mod_perl homepage <A HREF="http://perl.apache.org/">http://perl.apache.org/</A> has links to other
  +mod_perl resources.</P>
  +<P>The pod source of this FAQ is available at
  +<A HREF="http://www.ping.de/~fdc/mod_perl/mod_perl_faq.tar.gz">http://www.ping.de/~fdc/mod_perl/mod_perl_faq.tar.gz</A></P>
   <P>
  +<H2><A NAME="where do i send suggestions and corrections concerning this faq">Where do I send suggestions and corrections concerning this FAQ?</A></H2>
  +<P><A HREF="mailto:mailto:fdc@cliwe.ping.de">mailto:fdc@cliwe.ping.de</A></P>
   
  -</DL>
  -    </BODY>
  +</BODY>
   
  -    </HTML>
  +</HTML>
  
  
  
  1.8       +62 -95    modperl-site/faq/mod_perl_faq.pod
  
  Index: mod_perl_faq.pod
  ===================================================================
  RCS file: /home/cvs/modperl-site/faq/mod_perl_faq.pod,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- mod_perl_faq.pod	2001/06/02 13:55:33	1.7
  +++ mod_perl_faq.pod	2001/07/18 02:29:28	1.8
  @@ -1,6 +1,6 @@
   =head1 NAME
   
  -Mod_perl_faq - frequently asked questions about mod_perl ($Date: 2001/06/02 13:55:33 $)
  +Mod_perl_faq - frequently asked questions about mod_perl ($Date: 2001/07/18 02:29:28 $)
   
   =head1 DESCRIPTION
   
  @@ -49,25 +49,9 @@
   
   http://www.perl.com/CPAN/src/latest.tar.gz
   
  -Win32 users note: mod_perl compiles cleanly and works with ActivePerl
  -(build 626, June 2001).  In
  -http://www.mail-archive.com/modperl@apache.org/msg11513.html Randy
  -Kobes wrote:
  -
  -   A ppd for mod_perl, suitable for use with ActivePerls 
  -   based on Perl-5.6.0, is now available. Installation is as ppm
  -   install
  -
  -   http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd
  -
  -   or in ftp://theoryx5.uwinnipeg.ca/pub/ppmpackages/.
  -   A post-install script will subsequently be run which
  -   will download and install the required ApacheModulePerl.dll;
  -   this should be placed in your Apache modules directory.
  -   If for some reason the script fails, this dll can be
  -   obtained from http://theoryx5.uwinnipeg.ca/ppmpackages/.
  -   Also available in this directory is a sample Apache
  -   httpd.conf suitable to test mod_perl on Win32.
  +Win32 users note: at the time of writing, ActiveState's Perl cannot be
  +used with mod_perl, because it is based on an old version of perl
  +(perl-5.003_07, build 316).
   
   =item Apache
   
  @@ -77,30 +61,34 @@
   
   =head2 How do I install it?
   
  -Configuring and installing apache with mod_perl is a complex process,
  -so it is really not a good idea to attempt to do it manually.  If you
  -are used to configuring third-party modules into Apache using the
  -apache configuration process, please realize that running mod_perl's
  -Makefile.PL with the right parameters does this for you.
  -
  -Read the INSTALL* files in the top-level mod_perl distribution
  -directory and then choose one of the INSTALL.simple* recipes that is
  -close to your requirements, as a starting point.  When you succeed in
  -compiling and linking an httpd, a quick way to check that everything
  -is configured according to plan is to run it with the C<-l> (list
  -compiled-in modules) and C<-V> (show paths) flags.
  +Here is the easiest way to proceed.  Let's assume you have the latest
  +version of perl (5.004) installed.  Unpack the Apache and Mod_perl
  +tarballs next to one another under a common directory: e.g.
  +
  +  % cd /usr/local/src
  +  % zcat apache_1.2.0.tar.gz | tar xf -
  +  % zcat mod_perl-0.98_12.tar.gz | tar xf -
  +
  +You probably do not need to change anything in the apache configuration
  +before compiling.  Only if you want to enable additional non-standard
  +modules do you need to edit apache_1.2.0/src/Configuration.  There is no
  +need to set CC, CFLAGS, etc., because mod_perl will override them with the
  +values that were used to compile your perl.
  +
  +Now go to the mod_perl directory and follow the instructions in the
  +INSTALL file there.  If "make test" and "make install" are successful, you
  +will find the new web server in apache_1.2.0/src/httpd.  Move it to a
  +suitable location, make sure it has access to the correct configuration
  +files, and fire it up.
   
   =head2 What documentation should I read?
   
   The mod_perl documentation in mod_perl.pod.  After you have installed
   mod_perl you can read it with the command: C<perldoc mod_perl>.
   
  -The complete list of available documentation can be found at the end
  -of mod_perl's README file.
  -
   If you are using mod_perl to extend the server functionality, you will
   need to read C<perldoc Apache> and the Apache API notes, which can be
  -found in apache_x.x.x/htdocs/manual/misc/API.html.
  +found in apache_1.2.0/htdocs/manual/misc/API.html.
   
   Existing (perl-) CGI scripts should run as-is under mod_perl.  There are a
   number of reasons why they may need to be adjusted, and these are
  @@ -126,11 +114,6 @@
   information.  You would not want your /etc/passwd file to be readable over
   the net, for instance.
   
  -Different mod_perl scripts run successively using the same Perl
  -interpreter instance. So, in addition to classical CGI mischiefs, a
  -malicious mod_perl script can redefine any Perl object and change the
  -behavior of other mod_perl scripts.
  -
   If you turn on tainting checks, perl can help you to avoid the pitfalls of
   using data received from the net.  Setting the C<-T> switch on the first line
   of the script is not sufficient to enable tainting checks under mod_perl.
  @@ -142,7 +125,7 @@
   You will have to start a new process that runs under a suitable user-id
   (or group-id).  If all requests handled by the script will need the higher
   privileges, you might as well write it as a suid CGI script.  Read the
  -documentation about suEXEC in the Apache documentation.
  +documentation about suEXEC in Apache-1.2.
   
   Alternatively, pre-process the request with mod_perl and fork a suid
   helper process to handle the privileged part of the task.
  @@ -154,12 +137,11 @@
   Make sure that your scripts are not leaking memory.  Global variables
   stay around indefinitely, lexical variables (declared with my()) are
   destroyed when they go out of scope, provided there are no references
  -to them from outside of that scope.  The Apache::Leak module can warn
  -about some types of memory leak.
  +to them from outside of that scope.
   
   To get information about the modules that have been loaded and their
   symbol-tables, use the Apache::Status module.  It is enabled by adding
  -these lines to the httpd configuration file.
  +these lines to a configuration file (e.g. access.conf);
   
     <Location /perl-status>
     SetHandler  perl-script
  @@ -183,9 +165,19 @@
   =head2 Do I have to restart the server when I change my Perl code?
   
   Apache::Registry checks the timestamp of scripts that it has loaded
  -and reloads them if they change.  Other handlers and library modules
  -are not automatically reloaded by mod_perl, but you can use the
  -Apache::StatINC module to do this for you.
  +and reloads them if they change.  This does not happen for other
  +handlers, unless you program it yourself.  One way to do this is in a
  +PerlInitHandler.  If you define
  +
  +  sub MY::init {
  +      delete $INC{"YourModule.pm"};
  +      require YourModule;
  +  }
  +
  +as an init handler, it will unconditionally reload YourModule at the
  +start of each request, which may be useful while you are developing a
  +new module.  It can be made more efficient by storing the timestamp of
  +the file in a global variable and only reloading when necessary.
   
   =head2 So how do I use mod_perl in conjunction with ErrorDocument?
   
  @@ -282,16 +274,23 @@
   
   =head2 How can I reference private library modules?
   
  -If you put your modules into one of the directories on perl's search
  -path (the @INC array), they will be found automatically.
  -Traditionally, site-specific modules go in /usr/lib/perl5/site_perl/.
  -Newer versions of mod_perl add the directory $ServerRoot/lib/perl to
  -@INC on startup so that is a good place for modules that are only used 
  -by mod_perl scripts.
  -
  -If you need to load files from other non-standard locations, you can
  -add directories to the @INC array with a 'use lib' statement in a
  -startup script.  See L<mod_perl_tuning> for an example.
  +The best place to put library modules is in the site_perl directory
  +(usually /usr/lib/perl/site_perl), where perl will find them without
  +further ado.  Local policy may prevent this, in which case you have to
  +tell the perl interpreter where to find them by adding your private
  +directory to the @INC array.
  +
  +There are various ways to do this.  One way is to add
  +
  +  use lib '/my/perl/lib';
  +
  +to each script that needs modules from /my/perl/lib.
  +
  +Alternatively, you can arrange for all the modules that might be
  +needed to be loaded when the server starts up.  Put a PerlRequire
  +directive into one of the httpd config files that pulls in a small
  +module containing the relevant C<use>-statements.  There is an example
  +of this in L<mod_perl_tuning>.
   
   =head2 How can I pass arguments to a SSI script?
   
  @@ -314,7 +313,7 @@
   
     <!--#perl sub="My::ssi" arg="one" arg="two" arg="three" -->
   
  -=head2 Why is image-file loading so slow when testing with httpd C<-X> ?
  +=head2 Why is image-file loading so slow when testing with httpd -X ?
   
   If you use Netscape while your server is running in single-process
   mode, the "KeepAlive" feature gets in the way.  Netscape tries to open
  @@ -322,7 +321,7 @@
   server process listening, each connection has to time-out before the
   next succeeds.  Turn off KeepAlive in httpd.conf to avoid this effect.
   
  -=head2 What can cause a subroutine or variable to be sporadically undefined?
  +=head2 What can cause a subroutine to suddenly become undefined?
   
   If you sometimes see error messages like this:
   
  @@ -336,8 +335,7 @@
   require it, you need to be sure that the file containing sub_foo sets
   a package name.  Otherwise, sub_foo gets defined in the namespace that
   is active the first time it is required, and the next require is a
  -no-op because that file is already in %INC.  The same problem can
  -happen with global variables.
  +no-op because that file is already in %INC.
   
   The solution is simple, set up your require'd file something along
   these lines:
  @@ -348,16 +346,6 @@
   
   Now, have scripts call SomeName::sub_foo() instead of sub_foo().
   
  -=head2 Is there a bug that causes httpd processes to crash?
  -
  -You may see httpd child processes crashing with segmentation fault
  -when you restart the server with a HUP or USR1 signal.  This is not a
  -bug in mod_perl.  If you have 'PerlFreshRestart On' in the
  -configuration, the main httpd daemon reloads all the perl modules that
  -it has preloaded when it gets a HUP or USR1 signal.  Unfortunately,
  -not all perl modules are robust enough to survive this, for them,
  -unusual situation.
  -
   =head2 What could be causing sporadic errors "in cleanup"?
   
   Some people have seen error messages such as this:
  @@ -388,12 +376,6 @@
   starts up, whereas GATEWAY_INTERFACE may not be set yet when BEGIN
   blocks are being processed.
   
  -=head2 Why don't "format" and "write" work under mod_perl?
  -
  -The Perl tie'd filehandle interface is not complete, format/write is
  -one of the missing pieces.  If you configure Perl with sfio, write()
  -should work just fine.
  -
   =head2 Where can I get help that I did not find in here?
   
   There is a mailing-list dedicated to mod_perl.  It is archived at
  @@ -403,23 +385,8 @@
   http://www.progressive-comp.com/Lists/?l=apache-modperl&r=1#apache-modperl
   (threaded and indexed).
   
  -You can subscribe to the list by sending a mail to
  -C<modperl-subscribe@apache.org> and responding to the confirmation
  -message that you will receive.  To unsubscribe, send mail to
  -C<modperl-unsubscribe@apache.org> B<from the address you are
  -subscribed at> and reply to the confirmation message.  Look at the
  -full headers of mails that you receive from the list to see the
  -address that they were sent to.  The address is embedded in the
  -C<Return-Path> header (you will probably have to activate a "show full 
  -headers" function in your mail reader to see it).  To find the
  -address, delete C<modperl-return-nnnn-> from the front of the return path 
  -and C<@apache.org> from the back, then replace the C<=> with C<@>.
  -
  -Remember: the mailing list is for questions about and discussion of
  -mod_perl.  Quetions about perl programming in general should be asked
  -in the newsgroup comp.lang.perl.misc, after consulting the fine perl
  -faqs.  There is a whole set of newsgroups dedicated to web authoring,
  -web servers etc.: comp.infosystems.www.*
  +You can subscribe to the list by sending a mail with the line C<subscribe
  +modperl> to C<majordomo@apache.org>.
   
   The mod_perl homepage http://perl.apache.org/ has links to other
   mod_perl resources.
  
  
  

Mime
View raw message