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.
That being said. I have always found it strange that everything has to
check r->handler.
appear anywhere in the list, so "fall back to my CGI if there's no file of
that name" becomes "AddHandlerByExt .html default cgi-script".
ErrorDocuments are invoked when we fall off the end of the list.
What about cases like this?
<Location /stuff>
SetHandler stuff-handler
</Location>
where stuff may have all sorts of extensions.
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. Chains could be
built up as one shots (like SetHandler) or more elaborate like
mod_filter does with filters. the default_handler in core could always
be added to the end.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
