On Tuesday 04 October 2005 16:25, Brian Akins wrote: > Nick Kew wrote: > > The current implementation of handlers is a little bizarre, with each > > handler both having to register itself and check its own name. > > Some people, myself included, have handlers that run even when they > aren't "set," ithey never check r->handler and always returns DECLINED. > Yes, I know this is bad and should be done in fixups probably, but I'm > sure this may break some things.
Sounds contrary to the API. Flexible configuration would presumably enable you to insert them legitimately? > That being said. I have always found it strange that everything has to > check r->handler. Exactly. > What about cases like this? > > <Location /stuff> > SetHandler stuff-handler > </Location> That's easy: no change as far as stuff-handler is concerned. SetHandler gets to take extra args, but only if we want it (i.e. not in cases like that). > > For a slightly bigger change, we can use ap_provider on top of that to > > declare and reference handlers. > > This is interesting. But what if we had a "handler chain" much like a > filter chain? First one to return OK stops the chain. Indeed. But that's first one NOT to return DECLINED. > Chains could be > built up as one shots (like SetHandler) or more elaborate like > mod_filter does with filters. Even SetHandler could take more than one argument. In fact, that should serve to make SetHandler compatible with Directory Indexes - which people sometimes want in a cgi-bin type of situation. > the default_handler in core could always > be added to the end. I'd prefer not. It can be added anywhere, but needn't be implied except as a default (no explicit handler at all in effect). -- Nick Kew
