Mailing List Archive: ModPerl: ModPerl

Apache2::Request in PerlInitHandler and PerlAuthenHandler

Index | Next | Previous | View Threaded

shibi.ns at gmail

Oct 14, 2008, 1:28 AM

Post #1 of 8 (987 views)
Permalink

Apache2::Request in PerlInitHandler and PerlAuthenHandler

I have following Location directive in my applications conf file

<Location ~ ^/((download|ARULink|WebApp)/.*)?$>
PerlInitHandler ARULink::setup_request
SetHandler perl-script
PerlResponseHandler ARULink::handler
PerlOptions +ParseHeaders +GlobalRequest
Options ExecCGI
AuthName Metalink
AuthType Basic
PerlAuthenHandler ARULink::MetalinkAuth
require valid-user
ErrorDocument 401 /handle_auth_failure
</Location>

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/MetalinkAuth.pm
line 114.

Line File Sub Called Arg
WntA
---- ---- ---------- ---
----
359 Debug.pm Debug::stack_trace Y
N
114 MetalinkAuth.pm Debug::__ANON__ Y
N
114 MetalinkAuth.pm CGI::new Y
N
354 CGI.pm ARULink::MetalinkAuth::handler Y
N

..

Any idea how can we get the $req->args which contains request information
in PerlAuthenHandler or PerlInitHandler

--Shibi Ns--

aw at ice-sa

Oct 14, 2008, 2:12 AM

Post #2 of 8 (947 views)
Permalink

Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler [In reply to]

Hi.

It usually helps for any kind of support issue, if you provide some
information about where this is happening : what platform, which Apache
version, which perl version, which mod_perl version, etc..

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

For the same reason, the line
> Options ExecCGI
is not necessary, since you are not executing any cgi-bin scripts in
that directory, only mod_perl handlers.

Additionally, I am not quite sure of your line
> my $cgi = CGI->new($req_params);
I believe you should rather use
> my $cgi = CGI->new($req);
The CGI.pm module is smart enough, given the correct environment, to
figure out that it is running under mod_perl, and then use the request
object ($req) as a base to build the CGI object.

The above may well be why the CGI.pm library module is getting confused,
and spinning. So try the changes first, and come back if it still has a
problem.

Shibi NS wrote:
> I have following Location directive in my applications conf file
>
> <Location ~ ^/((download|ARULink|WebApp)/.*)?$>
> PerlInitHandler ARULink::setup_request
> SetHandler perl-script
> PerlResponseHandler ARULink::handler
> PerlOptions +ParseHeaders +GlobalRequest
> Options ExecCGI
> AuthName Metalink
> AuthType Basic
> PerlAuthenHandler ARULink::MetalinkAuth
> require valid-user
> ErrorDocument 401 /handle_auth_failure
> </Location>
>
>
> 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/MetalinkAuth.pm
> line 114.
>
>
> Line File Sub Called Arg
> WntA
> ---- ---- ---------- ---
> ----
> 359 Debug.pm Debug::stack_trace Y
> N
> 114 MetalinkAuth.pm Debug::__ANON__ Y
> N
> 114 MetalinkAuth.pm CGI::new Y
> N
> 354 CGI.pm ARULink::MetalinkAuth::handler Y
> N
>
> ..
>
> Any idea how can we get the $req->args which contains request information
> in PerlAuthenHandler or PerlInitHandler
>
> --Shibi Ns--
>

torsten.foertsch at gmx

Oct 14, 2008, 3:50 AM

Post #3 of 8 (949 views)
Permalink

Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler [In reply to]

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/MetalinkAuth.pm 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 CGI.pm? 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.

Torsten

--
Need professional mod_perl support?
Just hire me: torsten.foertsch [at] gmx

aw at ice-sa

Oct 14, 2008, 4:18 AM

Post #4 of 8 (957 views)
Permalink

Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler [In reply to]

Torsten Foertsch wrote:
> 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/MetalinkAuth.pm 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 CGI.pm? 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.
>
I mentioned that mainly because I thought it might have something to do
with the convoluted gymnastics that CGI.pm does to try and figure out if
it is running under mod_perl, and under which version of it.

But anyway, there is no reason to use perl-script here rather than
mod_perl. It adds overhead, without bringing any benefit in this case.
I believe the problem might be more tied to the following lines :

>> my $req_params = $req->args;
>> my $cgi = CGI->new($req_params);

Is CGI really expecting in this case to receive the $r->args as argument
to new() ?
Looking at the code, it seems to expect various things in various
devious ways, but $r->args does not seem to be one of them.

There is by the way a certain lack of documentation about the behaviour
of CGI.pm under mod_perl. It is mentioned in some obscure place that
CGI is "aware" of mod_perl, but not much more.
Not in CGI.pm documentation at any rate.

perrin at elem

Oct 14, 2008, 10:22 AM

Post #5 of 8 (939 views)
Permalink

Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler [In reply to]

On Tue, Oct 14, 2008 at 4:28 AM, Shibi NS <shibi.ns [at] gmail> wrote:
> my $req_params = $req->args;
> my $cgi = CGI->new($req_params);

There's no need to do that. Just call CGI->new(). And make sure you
have the latest version of CGI.pm from CPAN.

- Perrin

shibi.ns at gmail

Oct 14, 2008, 11:44 PM

Post #6 of 8 (941 views)
Permalink

Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler [In reply to]

Sorry I forgot this info,

platform (Unix) : Red Hat Enterprise Linux AS release 3 (Taroon Update 8)
Apache/2.2.9
mod_perl/2.0.4
CGI.pm version 3.15

Shibi Ns

Perl/v5.8.8

On Tue, Oct 14, 2008 at 2:42 PM, Andr� Warnier <aw [at] ice-sa> wrote:

> Hi.
>
> It usually helps for any kind of support issue, if you provide some
> information about where this is happening : what platform, which Apache
> version, which perl version, which mod_perl version, etc..
>
> 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
>
> For the same reason, the line
> > Options ExecCGI
> is not necessary, since you are not executing any cgi-bin scripts in that
> directory, only mod_perl handlers.
>
> Additionally, I am not quite sure of your line
> > my $cgi = CGI->new($req_params);
> I believe you should rather use
> > my $cgi = CGI->new($req);
> The CGI.pm module is smart enough, given the correct environment, to figure
> out that it is running under mod_perl, and then use the request object
> ($req) as a base to build the CGI object.
>
> The above may well be why the CGI.pm library module is getting confused,
> and spinning. So try the changes first, and come back if it still has a
> problem.
>
>
>
> Shibi NS wrote:
>
>> I have following Location directive in my applications conf file
>>
>> <Location ~ ^/((download|ARULink|WebApp)/.*)?$>
>> PerlInitHandler ARULink::setup_request
>> SetHandler perl-script
>> PerlResponseHandler ARULink::handler
>> PerlOptions +ParseHeaders +GlobalRequest
>> Options ExecCGI
>> AuthName Metalink
>> AuthType Basic
>> PerlAuthenHandler ARULink::MetalinkAuth
>> require valid-user
>> ErrorDocument 401 /handle_auth_failure
>> </Location>
>>
>>
>> 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/MetalinkAuth.pm
>> line 114.
>>
>>
>> Line File Sub Called
>> Arg
>> WntA
>> ---- ---- ----------
>> ---
>> ----
>> 359 Debug.pm Debug::stack_trace Y
>> N
>> 114 MetalinkAuth.pm Debug::__ANON__ Y
>> N
>> 114 MetalinkAuth.pm CGI::new Y
>> N
>> 354 CGI.pm ARULink::MetalinkAuth::handler Y
>> N
>>
>> ..
>>
>> Any idea how can we get the $req->args which contains request information
>> in PerlAuthenHandler or PerlInitHandler
>>
>> --Shibi Ns--
>>
>>
>

--
--Shibi Ns--

perrin at elem

Oct 15, 2008, 1:34 PM

Post #7 of 8 (932 views)
Permalink

Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler [In reply to]

On Wed, Oct 15, 2008 at 2:44 AM, Shibi NS <shibi.ns [at] gmail> wrote:
> CGI.pm version 3.15

Update.

- Perrin

shibi.ns at gmail

Oct 20, 2008, 9:57 AM

Post #8 of 8 (895 views)
Permalink

Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler [In reply to]

Thanks All for the valuable suggestions. my $cgi = CGI->new($req); fixed
my issue :)

On Thu, Oct 16, 2008 at 2:04 AM, Perrin Harkins <perrin [at] elem> wrote:

> On Wed, Oct 15, 2008 at 2:44 AM, Shibi NS <shibi.ns [at] gmail> wrote:
> > CGI.pm version 3.15
>
> Update.
>
> - Perrin
>

--
--Shibi Ns--

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads