+1
Excellent summary, Graham.
Maybe we could ask on the mod_pyhon mailing list who is stacking
non-content handlers, especially if registered dynamically, and for
what purpose ? This way we could make sure that no one actually relies
on the current cludgy behaviour.
But I agree with you, it's pretty sure that changing mod_python to
align with the standard Apache behaviour should not meet popular
disagreement, especially given the corner cases in which it really
matters :).
Regards,
Nicolas
2006/2/22, Graham Dumpleton <[EMAIL PROTECTED]>:
> Grisha wrote ..
> >
> > If I understand this correctly, then +1.
> >
> > ...though I'm wondering if anyone will actually try to do something as
> > arcane as dynamicaly registering non-content handers? :-)
>
> I agree, it might not be a totally realistic scenario, but then now that
> I have checked in a change to make req.handler writable, the system
> is becoming flexible enough that it may actually be reasonable to do
> it for some reason.
>
> Specifically, with the change to make req.handler writable, instead of
> using SetHandler/AddHandler to have mod_mime internally set
> req.handler to "mod_python", you could define your own type handler
> which did it.
>
> def typehandler(req):
> if os.path.splitext(req.filename)[1] == ".py":
> req.handler = "mod_python"
> req.add_handler("PythonHandler","mod_python.publisher")
> return apache.OK
> return apache.DECLINED
>
> You might even at the same time want to register a fixup handler
> to do stuff prior to the response phase being run:
>
> def typehandler(req):
> if os.path.splitext(req.filename)[1] == ".py":
> req.handler = "mod_python"
> req.add_handler("PythonFixupHandler","manage_session_object")
> req.add_handler("PythonHandler","mod_python.publisher")
> return apache.OK
> return apache.DECLINED
>
> For example, you might introduce a fixup handler which ensures that
> a session object is created and put in req.session. This is a lot cleaner
> than what most people do, which is to put a call to the session manager
> code in every single published function.
>
> Graham
>
> > On Tue, 21 Feb 2006, Jim Gallacher wrote:
> >
> > > Nice summary.
> > > +1 for the change.
> > >
> > > Jim
> > >
> > > Graham Dumpleton wrote:
> > >> Jim Gallacher wrote ..
> > >>
> > >>> I don't have alot more to say on these last 2 emails. I think you are
> > on
> > >>> the right path here.
> > >>
> > >>
> > >> Okay, I think I have a good plan now.
> > >>
> > >> To summarise the whole issue, the way Apache treats multiple handlers
> > in
> > >> a single phase for non content handler phases is as follows:
> > >>
> > >> PostReadRequestHandler RUN_ALL
> > >> TransHandler RUN_FIRST
> > >> MapToStorageHandler RUN_FIRST
> > >> InitHandler RUN_ALL
> > >> HeaderParserHandler RUN_ALL
> > >> AccessHandler RUN_ALL
> > >> AuthenHandler RUN_FIRST
> > >> AuthzHandler RUN_FIRST
> > >> TypeHandler RUN_FIRST
> > >> FixupHandler RUN_ALL
> > >>
> > >> LogHandler RUN_ALL
> > >>
> > >> RUN_ALL means run all handlers until one returns something other than
> > OK
> > >> or DECLINED. Thus, handler needs to return DONE or an error to have
> > it
> > >> stop
> > >> processing for that phase.
> > >>
> > >> RUN_FIRST means run all handlers while they return DECLINED. Thus, needs
> > >> handler to return OK, DONE or error to have it stop processing for that
> > >> phase.
> > >>
> > >> Where multiple handlers are registered within mod_python for a single
> > >> phase it doesn't behave like either of these. In mod_python it will
> > keep
> > >> running the handlers only while OK is returned. Returning DECLINED
> > >> causes it to stop. This existing behaviour can be described (like
> > >> mod_perl)
> > >> as stacked handlers.
> > >>
> > >> Having non content handler phases behave differently to how Apache does
> > >> it causes problems. For example things like a string of authentication
> > >> handlers which only say OK when they handle the authentication type,
> > >> can't be implemented properly. In Apache, it should stop the first time
> > >> one returns OK, but in mod_python it will keep running the handlers
> > >> in that phase.
> > >>
> > >> In summary, it needs to behave more like Apache for the non content
> > >> handler phases.
> > >>
> > >> In respect of the content handler phase itself, in practice only one
> > >> handler
> > >> module is supposed to implement it. At the Apache level there is no
> > >> concept of different Apache modules having goes at the content handler
> > >> phase and returning DECLINED if they don't want to handle it. This is
> > >> reflected in how in the type handler phase, selection of the module
> > to
> > >> deliver content is usually done by setting the single valued req.handler
> > >> string. Although, when using mod_python this is done implicitly by
> > >> setting the SetHandler/AddHandler directives and mod_negotiation then
> > >> in turn setting req.handler to be mod_python for you.
> > >>
> > >> Because mod_python when executed for the content handler phase is
> > >> the only thing generating the content, the existing mechanism of
> > >> stacked handlers and how the status is handled is fine within just
> > >> the content handler phase. Can thus keep that as is and no chance of
> > >> stuffing up existing systems.
> > >>
> > >> Where another phase calls req.add_handler() to add a handler or multiple
> > >> handlers for the "PythonHandler" (content) phase, these will be added
> > in
> > >> a stacked manner within that phase. This also is the same as it works
> > now.
> > >> There would be non need to have a new function to add stacked handlers
> > >> as that behaviour would be dictated by phase being "PythonHandler".
> > >>
> > >> For all the non content handler phases though, the current stacked
> > >> handlers algorithm used by mod_python would be replaced with how
> > >> Apache does it. That is, within multiple handlers registered with
> > >> mod_python
> > >> for non content handler phase, it would use RUN_FIRST or RUN_ALL
> > >> algorithm as appropriate for the phase.
> > >>
> > >> For those which use RUN_ALL, this wouldn't be much different than what
> > >> mod_python does now except that returning DECLINED would cause it
> > >> to go to next mod_python handler in that phase instead of stopping.
> > >> It is highly unlikely that this change would have an impact as returning
> > >> DECLINED in RUN_ALL phases for how mod_python currently implements
> > >> it, tends not to be useful and can't see that anyone would have been
> > using
> > >> it.
> > >>
> > >> For those which use RUN_FIRST, the difference would be significant as
> > >> reurning OK will now cause it to stop instead of going to next mod_python
> > >> handler in the phase. Personally I don't think this would be a drama
> > as
> > >> not many people would be using these phases and highly unlikely that
> > >> someone would have listed multiple handlers for such phases. If they
> > had
> > >> and knew what they were doing, they should have long ago realised that
> > >> the current behaviour was a bit broken and it even probably stopped
> > them
> > >> from doing what they wanted unless they fudged it.
> > >>
> > >> As to use of req.add_handler() for non content handler phases, each
> > call
> > >> would create a distinct handler, ie., no stacking of handlers at all.
> > No
> > >> separate function is required though, as slight change in behaviour
> > >> determine form phase specified.
> > >>
> > >> To sum up, I think these changes would have minimal if no impact as
> > >> where changes are significant, it isn't likely to overlap with existing
> > >> code
> > >> as shortcomings in current system would have mean't people wouldn't
> > >> have been doing the sorts of things that may have been impacted.
> > >>
> > >> Therefore, I don't see a need for this to be switch enabled and the
> > >> change could just be made and merely documented.
> > >>
> > >> Luckily the changes to make it work like above should be fairly easy.
> > All
> > >> it will entail is changing CallBack.HandlerDispatch() to treat status
> > >> differently dependent on phase. No changes to req.add_handler() or
> > >> code processing directives will be required.
> > >>
> > >> Graham
> > >>
> > >>
> > >
>
