You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dan Jacobowitz <dr...@false.org> on 1998/07/28 23:32:01 UTC

The further saga of DSO and modperl

[I'm crossposting this to new-httpd and modperl; please CC any
responses on new-httpd to me]

I was trying to figure out why PERL_STACKED_HANDLERS is completely
failing in DSO situations, and I have one idea...If I push a
PerlHandler it does correctly get executed when SetHandler perl-script
is used.  The problem, then, is that PerlHandler is not pushing the
handler!

For instance, this fails (in 1.3.1 without even a warning):

<Location /perl-status>
SetHandler perl-script
PerlHandler Apache::Status
</Location>

But this succeeds:
<Location /perl-status>
SetHandler perl-script
<Perl>
Apache->push_handlers(PerlHandler => \&Apache::Status::handler);
</Perl>
</Location>



--------------
Time lapse while MCI dies again...
--------------

Fixed!
The code for perl-section handles being called before perl_startup by
calling perl_startup.  So, simply do that here too.  Of course, a
better solution is needed; before ANY of these routines get called, I
would think, perl_startup() [the module initializer] should have gotten
called, no?  That certainly seems to be an assumption of the code.

A patch which forces at least PerlHandler to work is enclosed, but we
need to find a real solution before committing this - it doesn't fix
PerlAuthzHandler, for instance.  I considered putting the call in
perl_cmd_push_handlers, but I could not see off the top of my head
where to get parms->server, so I stuck this in as a quick fix. 
Incidentally, sticking a <Perl> section at the top of your httpd.conf,
even with nothing in it, should fix the problem.

So - when is perl_startup being called, and when is it not?  Thoughts?

Dan