You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by judy selen <ju...@wolfram.com> on 2001/02/01 20:29:07 UTC

Re: Newbie mysterious 500 error with PerlFixupHandlers

  We are using
  RedHat Linux apache 1.3.14 mod_perl_1.23_01
  
  Our site is set up to generate pages using a templating system to add
  custom headers footers and sidebars. As well we use .htaccess files to 
  further customize the subprocess_env.
 
  We are using custom modules installed as PerlFixupHandlers both for
 template generation and multilingual negotiation 
  
Negotiation.pm  handles lingual content negotiation. It determines
 what version of the page to present based on the users preferred
 variants and the available variants for that page.When the best match
is found, it 
performs an internal redirect to that document.

Template.pm is installed as a fixup handler, and is controlled through
various PerlSetVar directives.
 Basically, it determines what to include at the beginning and end of
the web page. 
fixup sets the content handler for the request.
 Also has two subroutines, handle_rec for static pages ,and handle_cgi
for scripts These allow the auto-inclusion of headers and footers of web
pages. 

 In httpd.conf
--------------
  DirectoryIndex index.cgi index.html 
 
  PerlRequire /www/perl/libs/WRI/Template.pm
  PerlRequire /www/perl/libs/WRI/Negotiation.pm
  
  PerlFixupHandler  WRI::Negotiation WRI::Template::fixup
---------------------------------------------------  

   These modules work 90% of the time....
      
  The problem occurs when a directory is requested, and served as a
 negotiated document
  and is passed to our content handler. (handle_cgi)
  A save-as window pops up in the browser and Apache logs a 500
  error. (The file it is trying to save is the standard 500 internal
error message.)
  In the Template::fixup handler, the
 document is being detected as a cgi-script, not a server-parsed
 document.  The 500 occurs because we are trying to execute a static 
 document or directory.  
 
 Template.pm
 In run_cgi:
 
  unless (open(CGI,'-|')) {
         #don't need the writing handle to the pipe anymore
         close(WR); 
         
         #make STDIN be the read handle of the pipe (so we can get 
         #POST information from Apache)
         open(STDIN,'<&RD');
 
         #Run in the directory of the file
         $r->chdir_file($filename); 

### This returns 500 when a directory or static file is negotiated ###

         #Run the file
         exec($filename) || return SERVER_ERROR;
     }
 
  
Error Log:

 [Wed Jan 31 13:04:52 2001] [error] Can't use string ("500") as a symbol
  ref while "strict refs" in use at /www/perl/libs/WRI/Template.pm line
  302.
  
  [Wed Jan 31 13:04:55 2001] [error] Usage: Apache::cgi_header_out(r,
 key,
  ...) at /www/perl/libs/WRI/Template.pm line 433.
  
  These lines numbers may not be accurate since we have added and
deleted
  debugging code..
 
 
  Template.pm - handle_cgi:
  
    #FIXME - needs error checking.  If run CGI fails, $cgi will have 
     #        the number 500 instead of a file handle, and will fail
 later on
 
      my $cgi = run_cgi($r, $r->filename(), $r->uri());
 
  line 302:
   while (<$cgi>) {
  
          #remove the trailing body and html tags from the CGI output
          #if we are using includes
          if ($addincs) {
 
              s!</(body|html)[^>]*>!!gio;
          }
  
          #print out the line that we just read
          $r->print($_);
      }
  
.
.
.

    do {
              #Quit if this is the end of the headers
              last if ($_ eq $/);
  
              #remove the LF or CRLF
              chomp;
 
              #Give apache the header line
              unless ($is_sub) {
    line 433:      $r->cgi_header_out(split(/:\s*/,$_,2));
              }
          } while (<CGI>);
 
 
  ---------------------------------------------
 
  My understanding is that when OK or DECLINED is returned from these
  modules in the list of fixup handlers, control passes to the next,
  and when DONE is returned, the remaining  are
  skipped mod_dir regains control and the next default file is requested
  (index.cgi index.html)
  
  Is this correct or is there something I am misunderstanding.

Request Outline
---------------
mod_dir sends directory request to Negotiation.pm

/products/student/calcwiz/
returns OK from Nego.pm 
mod_dir then sends index.cgi - index.html
Nego.pm negotiates index.cgi and each of available variations
    then index.html ......

when found most appropriate
Negotiating:
/products/student/calcwiz/index.en.html

Template.pm
 handling request..
/products/student/calcwiz/index.en.html



  Another Clue
  This error recurs when the page is reloaded 25 - 30 times
  MaxRequestsPerChild is 30
 Could this be related to our problem.
 
 I appreciate any clues anyone may have to why this problem occurs.
 Thanks in advance,
 Judy

Repost with code: Newbie mysterious 500 error with PerlFixupHandlers

Posted by judy selen <ju...@wolfram.com>.
Sorry I forgot to include these files with the earlier message.
Does anyone have any clues with this problem.
I have searched the archives for internal server errors and
PerlFixupHandlers 
and found no similar problems. Perhaps this is a mod_dir issue.
Judy


judy selen wrote:
> 
>   We are using
>   RedHat Linux apache 1.3.14 mod_perl_1.23_01
> 
>   Our site is set up to generate pages using a templating system to add
>   custom headers footers and sidebars. As well we use .htaccess files to
>   further customize the subprocess_env.
> 
>   We are using custom modules installed as PerlFixupHandlers both for
>  template generation and multilingual negotiation
> 
> Negotiation.pm  handles lingual content negotiation. It determines
>  what version of the page to present based on the users preferred
>  variants and the available variants for that page.When the best match
> is found, it
> performs an internal redirect to that document.
> 
> Template.pm is installed as a fixup handler, and is controlled through
> various PerlSetVar directives.
>  Basically, it determines what to include at the beginning and end of
> the web page.
> fixup sets the content handler for the request.
>  Also has two subroutines, handle_rec for static pages ,and handle_cgi
> for scripts These allow the auto-inclusion of headers and footers of web
> pages.
> 
>  In httpd.conf
> --------------
>   DirectoryIndex index.cgi index.html
> 
>   PerlRequire /www/perl/libs/WRI/Template.pm
>   PerlRequire /www/perl/libs/WRI/Negotiation.pm
> 
>   PerlFixupHandler  WRI::Negotiation WRI::Template::fixup
> ---------------------------------------------------
> 
>    These modules work 90% of the time....
> 
>   The problem occurs when a directory is requested, and served as a
>  negotiated document
>   and is passed to our content handler. (handle_cgi)
>   A save-as window pops up in the browser and Apache logs a 500
>   error. (The file it is trying to save is the standard 500 internal
> error message.)
>   In the Template::fixup handler, the
>  document is being detected as a cgi-script, not a server-parsed
>  document.  The 500 occurs because we are trying to execute a static
>  document or directory.
> 
>  Template.pm
>  In run_cgi:
> 
>   unless (open(CGI,'-|')) {
>          #don't need the writing handle to the pipe anymore
>          close(WR);
> 
>          #make STDIN be the read handle of the pipe (so we can get
>          #POST information from Apache)
>          open(STDIN,'<&RD');
> 
>          #Run in the directory of the file
>          $r->chdir_file($filename);
> 
> ### This returns 500 when a directory or static file is negotiated ###
> 
>          #Run the file
>          exec($filename) || return SERVER_ERROR;
>      }
> 
> 
> Error Log:
> 
>  [Wed Jan 31 13:04:52 2001] [error] Can't use string ("500") as a symbol
>   ref while "strict refs" in use at /www/perl/libs/WRI/Template.pm line
>   302.
> 
>   [Wed Jan 31 13:04:55 2001] [error] Usage: Apache::cgi_header_out(r,
>  key,
>   ...) at /www/perl/libs/WRI/Template.pm line 433.
> 
>   These lines numbers may not be accurate since we have added and
> deleted
>   debugging code..
> 
> 
>   Template.pm - handle_cgi:
> 
>     #FIXME - needs error checking.  If run CGI fails, $cgi will have
>      #        the number 500 instead of a file handle, and will fail
>  later on
> 
>       my $cgi = run_cgi($r, $r->filename(), $r->uri());
> 
>   line 302:
>    while (<$cgi>) {
> 
>           #remove the trailing body and html tags from the CGI output
>           #if we are using includes
>           if ($addincs) {
> 
>               s!</(body|html)[^>]*>!!gio;
>           }
> 
>           #print out the line that we just read
>           $r->print($_);
>       }
> 
> .
> .
> .
> 
>     do {
>               #Quit if this is the end of the headers
>               last if ($_ eq $/);
> 
>               #remove the LF or CRLF
>               chomp;
> 
>               #Give apache the header line
>               unless ($is_sub) {
>     line 433:      $r->cgi_header_out(split(/:\s*/,$_,2));
>               }
>           } while (<CGI>);
> 
> 
>   ---------------------------------------------
> 
>   My understanding is that when OK or DECLINED is returned from these
>   modules in the list of fixup handlers, control passes to the next,
>   and when DONE is returned, the remaining  are
>   skipped mod_dir regains control and the next default file is requested
>   (index.cgi index.html)
> 
>   Is this correct or is there something I am misunderstanding.
> 
> Request Outline
> ---------------
> mod_dir sends directory request to Negotiation.pm
> 
> /products/student/calcwiz/
> returns OK from Nego.pm
> mod_dir then sends index.cgi - index.html
> Nego.pm negotiates index.cgi and each of available variations
>     then index.html ......
> 
> when found most appropriate
> Negotiating:
> /products/student/calcwiz/index.en.html
> 
> Template.pm
>  handling request..
> /products/student/calcwiz/index.en.html
> 
>   Another Clue
>   This error recurs when the page is reloaded 25 - 30 times
>   MaxRequestsPerChild is 30
>  Could this be related to our problem.
> 
>  I appreciate any clues anyone may have to why this problem occurs.
>  Thanks in advance,
>  Judy