Can anybody explain this?

[Rob Tanner <rt...@onlinemac.com>]

Here's the scenario:

I have a modperl program I've been working on for a while (my first, so I'm 
a newbie).  I was having problem getting php to run and discovered that if 
modperl was configured, it ran fine.  But it wasn't my immediate priority, 
so I let it slide.  This evening, I discovered a similar problem with 
cgi-bin scripts.  I found that if my modperl script is sandwiched in a 
<location></location> directive, everything works as advertised (cgi and 
php).  In otherwords:

<location /foo>
  SetHandler perl
  PerlHandler Apache::foofoo
</location>

But if I remove the location directive (the module looks at $r->filename to 
see if it's the object of the get request), it all breaks again -- i.e., 
cgi and php, the module works in either case.  This is even true if the 
very first statement in the module is "return DECLINED;" which should not 
be necessary since the perl module shouldn't even see the cgi request.  And 
just to satisfy myself, I confirmed that assumption absolutely with a 
couple of print statements to STDERR (prints to the error_log).

What is actually going on here?  I loose some useful but not essential 
functionality by using location and/or directory directives, and I would 
prefer not to.  What do I need to do to fix it?

Thanks much.

-- Rob

       _ _ _ _           _    _ _ _ _ _
      /\_\_\_\_\        /\_\ /\_\_\_\_\_\
     /\/_/_/_/_/       /\/_/ \/_/_/_/_/_/  QUIDQUID LATINE DICTUM SIT,
    /\/_/__\/_/ __    /\/_/    /\/_/          PROFUNDUM VIDITUR
   /\/_/_/_/_/ /\_\  /\/_/    /\/_/
  /\/_/ \/_/  /\/_/_/\/_/    /\/_/         (Whatever is said in Latin
  \/_/  \/_/  \/_/_/_/_/     \/_/              appears profound)

  Rob Tanner
  McMinnville, Oregon
  rtanner@onlinemac.com

Re: Can anybody explain this?

[Doug MacEachern <do...@covalent.net>]

On Sat, 17 Jun 2000, Rob Tanner wrote:

> Here's the scenario:
> 
> I have a modperl program I've been working on for a while (my first, so I'm 
> a newbie).  I was having problem getting php to run and discovered that if 
> modperl was configured, it ran fine.  But it wasn't my immediate priority, 
> so I let it slide.  This evening, I discovered a similar problem with 
> cgi-bin scripts.  I found that if my modperl script is sandwiched in a 
> <location></location> directive, everything works as advertised (cgi and 
> php).  In otherwords:
> 
> <location /foo>
>   SetHandler perl
>   PerlHandler Apache::foofoo
> </location>
> 
> But if I remove the location directive (the module looks at $r->filename to 
> see if it's the object of the get request), it all breaks again -- i.e., 
> cgi and php, the module works in either case.  This is even true if the 
> very first statement in the module is "return DECLINED;" which should not 
> be necessary since the perl module shouldn't even see the cgi request.  And 
> just to satisfy myself, I confirmed that assumption absolutely with a 
> couple of print statements to STDERR (prints to the error_log).
> 
> What is actually going on here?  I loose some useful but not essential 
> functionality by using location and/or directory directives, and I would 
> prefer not to.  What do I need to do to fix it?

the problem is that without the <Location>, SetHandler perl-script applies
to every request, only mod_perl can handle that type, so returning
DECLINED doesn't help.  you'd be better off with a PerlFixupHandler (and
no SetHandler perl-script), let the FixupHandler decide if the request
should be handled by mod_perl, and if so:
$r->handler('perl-script');
$r->push_handlers(PerlHandler => \&Apache::foo);