perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject a new stacked handlers paradigm
Date Fri, 30 May 2003 17:55:10 GMT
hi all...

   I'd like to talk about the behavior of the stacked handler mechanism in mp2.

   as we all know, handler return codes mean different things for different 
phases.  for instance,  returning OK from a fixup handler in Apache (C 
modules, this is) lets the next fixup run, while returning OK from a trans 
handler terminates the translation phase.  in Apache 2.0, the following 
"programmable" request phases allow handlers returning OK to end the phase 
(taken from server/request.c)

                             (request_rec *r), (r), DECLINED)
                             (request_rec *r), (r), DECLINED)
                             (request_rec *r), (r), DECLINED)
                             (request_rec *r), (r), DECLINED)

the content handler (not listed here) also behaves this way.

anyway, the current (mp1 and mp2) stacked handler mechanism does _not_ 
follow this idiom - any and all configured stacked handlers are run for each 
phase, regardless of the meaning of that phase to Apache.  I think this 
behavior is wrong and should be fixed in 2.0.

why is it wrong?  consider this

   PerlAuthenHandler My::Returns::OK My::Returns::AUTH_REQUIRED

in this situation, the first authen handler returns OK, which _should_ mean 
the user was authenticated and can proceed.  indeed, that is what it means 
to Apache when mod_perl returns OK for the phase.  however, with mod_perl 
handlers the second handler is run and mod_perl returns AUTH_REQUIRED for 
the entire phase.  this is very unDWIMmy.

basically, all the stuff we tell people about "the first trans handler to 
return OK ends the translation phase" is true, but only if there are no 
stacked Perl handlers - if there are, the typical advice becomes bogus. 
this confusioon actually has bitten a few people and has come up on the list 
several times.  Apache::AuthenCache in particular comes to mind, as it needs 
to jump through lots of hoops in order to Do The Right Thing.

at any rate, I think that blindly running all stacked Perl handlers for each 
phase is wrong.  it does not keep with the nature of what Perl handler 
writers want to do, namely interact transparently with Apache as though they 
were writing C handlers.  having stacked handlers behave differently in C 
and Perl is confusing and, as it turns out, unnecessary - while for the 
first four stages it will probably impact people very little (and only in a 
good way), the only real value in mp1 in having handlers return OK _and_ 
running the next handler was with content handlers, but in 2.0 this is what 
output filters are for :)

so, what I'm suggesting is that we make the stacked handler mechanism more 
intelligent and Apache-like, and let the phases behave the same way for Perl 
handlers as they do for Apache.  that is, let handlers returning OK end the 
phase for translation, authen, authz, type-checking, and content.

keep in mind that in doing this we're not really taking away any 
functionality - handlers (in the 5 phases in question) can still return 
DECLINED if they want other handlers within the phase to run.  all that we 
would be changing is the behavior of OK in phases that Apache already treats 

anyway, here is a patch (attached due to long lines) to implement what I'm 
talking about.  all tests pass (after some tweaking :) except for the 
mod_include tests, which use stacked response handlers in a way that we 
should really be advocating filters for - so, you can either buy into my 
argument or we can keep response handlers stackable with OK (it only means 
changing a FALSE to TRUE once the rest of the infrastructure is applied :).

discussion welcome.


View raw message