perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Foertsch <>
Subject Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler
Date Tue, 14 Oct 2008 10:50:59 GMT
On Tue 14 Oct 2008, Shibi NS wrote:
> And the ARULink::MetalinkAuth::handler is
> sub handler
> {
>     my ($req) = @_;
>     my $status;
>     my $username;
>     my $userid;
>     my $email;
>     #
>     # Create a Session object.
>     #
>     my $req_params = $req->args;
>     my $cgi        = CGI->new($req_params);
>     my $session    = ARU::Session::get_cgi_session($cgi);
>     $req->subprocess_env;
>     ....
> }
> When my handler reaches line '(my $cgi    = new CGI($params);)' the
> application is spinning ,seems like $req->args is returning null and
> application line number 354 of CGI which is $req->subprocess_env;
> Error from log file
> Warning:
> Deep recursion on subroutine "CGI::new" at
> /m/isd/pm/ARULink/ line 114.

Don't know about CGI in this context but is there any chance to switch 
to Apache2::Request (libapreq2)?

If you really see an empty $r->args at that stage while you are certain 
to have passed something then it is an error in mod_perl. Try to create 
a test case as short and simple as you can and file a bugreport.

Try something like

  warn "params: ".$req->args;

The warning will appear in the error_log.

Can you please be more detailed about where it spins in My 
version 3.29 looks like:

   350    if ($MOD_PERL) {
   351      if ($MOD_PERL == 1) {
   352        $self->r(Apache->request) unless $self->r;
   353        my $r = $self->r;
   354        $r->register_cleanup(\&CGI::_reset_globals);
   355      }
   356      else {
   357        # XXX: once we have the new API
   358        # will do a real PerlOptions -SetupEnv check
   359        $self->r(Apache2::RequestUtil->request) unless $self->r;
   360        my $r = $self->r;
   361        $r->subprocess_env unless exists $ENV{REQUEST_METHOD};
   362        $r->pool->cleanup_register(\&CGI::_reset_globals);
   363      }
   364      undef $NPH;
   365    }

Line 354 is somewhere in the mp1 code path. The mp2 code path looks 
correct for me. Apache2::RequestUtil->request is set up in 
postreadrequest and again in headerparser if +GlobalRequest. 
cleanup_register() is also allowed here.

Ah, does your code check for a subrequest? Something like "return ... if 
$r->main" or "return ... unless $r->is_initial_req"? If not you may see 
it spinning in the subprocess_env line if your $r->path_info is not 
empty. The reason is a subrequest issued during $r->subprocess in void 
context to compute the standard CGI variable $ENV{PATH_TRANSLATED}. 
Apache does that by $r->lookup_uri($r->path_info). Assuming you don't 
have a download, ARULink or WebApp directory in your DocumentRoot the 
whole URI will be in $r->path_info as well. So, the subrequest will hit 
the same location container an thus the authen handler. Just a guess.

On Tue 14 Oct 2008, André Warnier wrote:
> Now, below :
>  > SetHandler              perl-script
> is used when your purpose is to run a "traditional" cgi-bin script
> under mod_perl, not for embedded modules like your
>  > PerlResponseHandler     ARULink::handler
> would indicate.
> I suggest you try replacing this first by
> SetHandler modperl

Sorry André but that is not entirely true. perl-script vs. modperl 
simply means you want the more sophisticated response handler. It 
affects only the response phase. Since the authen handler comes prior 
to that it is irrelevant here. More sophisticated means you want %ENV 
tied to $r->subprocess_env, tied *STDIN, *STDOUT, etc. The main reason 
for me to avoid the perl-script handler is that it uses PerlOptions 
+SetupEnv as default. That calls ap_add_cgi_vars() and that computes 
$ENV{PATH_TRANSLATED} the IMHO most useless CGI variable. To do that it 
issues a subrequest.


Need professional mod_perl support?
Just hire me:

View raw message