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);
