Apache handlers post-DECLINED

[Jason Kaskel <jk...@gmail.com>]

I've written a PerlHandler module that does some checking, then
returns either DECLINED or FORBIDDEN.  If it returns DECLINED the uri
that was requested gets processed by the content handler and returned.
 This works as expected if the requested uri is a vanilla .html page. 
However if the uri is a perl script, instead of the perl script being
executed, the source code is returned.  Any suggestions how to force
Apache to treat the uri like it would have, had I not stuck the
PerlHandler in there?

Example of what I mean:
-user tries to access www.something.com/page.html
-Apache::MyModule does some checking and returns DECLINED
-Apache processes page.html and it gets returned to the user as expected

-user tries to access www.something.com/page.cgi
-Apache::MyModule does some checking and returns DECLINED
-Apache processes page.cgi as an .html document and returns the source
of page.cgi instead of executing it; BAD!

If I disable Apache::MyModule the script gets executed by Apache as
expected (in case anyone was going to suggest that I make sure Apache
is set up to handle perl scripts correctly; it is).

(In case it's suggested, I can't currently use PerlAuthenHandler or
any handler other than PerlHandler.  The module makes use of mod_ssl
environment variables which are not accessible until the PerlHandler
phase.  I also can't make use of Geoff Young's module that works
around this [Apache::SSLLookup] because I'm forced to run Apache 1.3.)

Thanks for any help.

Jason
jkaskel@gmail.com

Re: Apache handlers post-DECLINED

[Geoffrey Young <ge...@modperlcookbook.org>]

Geoffrey Young wrote:
>>(In case it's suggested, I can't currently use PerlAuthenHandler or
>>any handler other than PerlHandler.  The module makes use of mod_ssl
>>environment variables which are not accessible until the PerlHandler
>>phase.  I also can't make use of Geoff Young's module that works
>>around this [Apache::SSLLookup] because I'm forced to run Apache 1.3.)
> 
> 
> IIRC those mod_ssl-specific variables (like HTTPS) are actually populated
> during fixups, which means if you can force mod_ssl to run its fixups
> _before_ mod_perl runs its fixups you'll be in good shape...

oh, and if it wasn't obvious what this buys you here it is - if mod_ssl runs
its fixups before mod_perl then you can code logic around, say,
$r->subprocess_env('HTTPS') from a PerlFixupHandler and leave the
PerlHandler to just serving content.

sorry I left that out :)

--Geoff

Re: Apache handlers post-DECLINED

[Geoffrey Young <ge...@modperlcookbook.org>]

> (In case it's suggested, I can't currently use PerlAuthenHandler or
> any handler other than PerlHandler.  The module makes use of mod_ssl
> environment variables which are not accessible until the PerlHandler
> phase.  I also can't make use of Geoff Young's module that works
> around this [Apache::SSLLookup] because I'm forced to run Apache 1.3.)

IIRC those mod_ssl-specific variables (like HTTPS) are actually populated
during fixups, which means if you can force mod_ssl to run its fixups
_before_ mod_perl runs its fixups you'll be in good shape...

one way to do this is to use ClearModuleList and AddModule to configure
mod_ssl lower in httpd.conf than mod_perl.  this would give mod_ssl higher
priority in the module list, making it run before mod_perl for all request
phases.  now, this may have unintended consequences if you plan to use
mod_perl to program any of the phases that mod_ssl hooks into, including
translation, access, auth, and authz.  but if you're only using the
PerlHandler you should be ok.

another option is something like this:

  package My::Fixup;
  use Apache::Module;  # from CPAN
  sub handler {
     my $r = shift;
     my $cv = Apache::Module->find('ssl')->fixer_upper;
     $r->$cv();
     return OK
  }

or somesuch.  see recipe 8.9 in the mod_perl developer's cookbook for more...

despite it's coolness, this is a very unorthodox approach.  but it just
might do what you need :)

--Geoff