httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: Flexible Handlers
Date Tue, 04 Oct 2005 15:40:50 GMT
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.


> 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

View raw message