httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: How to Handle Handlers and Order Hooks (and Other Matters)
Date Mon, 01 Jan 2001 12:35:49 GMT
Stunned you into silence, eh? I need some feedback one way or the other.
Or should I just do it and await the screams?

Cheers,

Ben.

Ben Laurie wrote:
> 
> OK, so the obvious thing is that handlers should be sorted like hooks. I
> initially thought that they should also be sorted according to their
> wildness but the more I think about it, the more I think that the whole
> handler structure should disappear and be replaced by YAH (Yet Another
> Hook). The down side of this is a slight loss of efficiency. The upside
> is that handlers can be more subtle about how they match the content
> type/handler string (and other things they may want to match), when they
> match it, and how they interact with other handlers.
> 
> You could argue that they could still do this with an extension of the
> current system (i.e. string matching as a prefilter before calling the
> handler, which then can be more subtle if desired). Yes, this is true,
> but the same must surely be true of all sorts of other hooks, so why
> single this one out? Also, it reduces the clarity of the process and
> potentially makes handlers do silly things (like match "*" because they
> really want to match something completely different) in order to squeeze
> into the structure.
> 
> So, what I'm inclined to think is that if we want to use "hints" to
> prefilter hook calls, we should do it in general, not just for handlers.
> 
> With that out of the way, I'd propose to axe the handler structure, and
> introduce a new handler_hook, which would look like this:
> 
> int handler_hook(const char *handler, request_rec *r);
> 
> where handler is the thing currently matched against the string (i.e.
> the handler set by SetHandler and friends, or the MIME type). It can
> return DECLINED, OK or an error. Anything except DECLINED will stop
> processing. Obviously, the first thing most handlers will do is a string
> comparison against handler...
> 
> OK, next is the question of configured control of ordering.
> 
> This one is potentially really easy. We just leverage the existing
> {prede,suc)cessor arguments in the hooking calls. What we do is allow
> the config file to specify ordering between pairs of modules for a
> particular hook, something akin to:
> 
> HookOrder handler mod_dir mod_autoindex
> 
> which would cause mod_dir's handler hook to run before mod_autoindex'.
> There are two issues, one new, one not new. The first is naming - we
> _really_ should have a global namespace for modules. Its time to stop
> avoiding this question! I propose we use something akin to Java -
> derived from DNS. I see no need to use backwards DNS, though. My initial
> thought is that global module names would look like this:
> "<FQDN>/<localname>". So, mod_autoindex would be
> "httpd.apache.org/autoindex", for example. Mod_backhand would be
> "cnds.jhu.edu/backhand" (say). Then the HookOrder directive would look
> like:
> 
> HookOrder handler httpd.apache.org/dir httpd.apache.org/autoindex
> 
> (if people object the URL-ish look, we could use "-" instead of "/",
> which makes it clear we're doing something totally different). Oh, I'd
> include the module name somewhere in the module structure, so we can
> enumerate them, BTW.
> 
> OK, the other issue is this - should we introduce the concept of
> mandatory and overridable {prede,suc}cessors? The idea being that
> overridable ones can be overridden by config (but specify the "usually
> appropriate" order), but mandatory ones can't? Or should we say that if
> they are what we'd consider overridable, then they MUST be configured. I
> don't hugely like the second option, because I firmly believe that you
> should be able to run Apache with an almost empty configuration. And,
> that it should be as obvious as possible what needs configuring when it
> does.
> 
> Oh, BTW, if we do this, we get I/O filtering ordering for free. Cool, or
> what?
> 
> So, once more, opinions, please.
> 
> Cheers,
> 
> Ben.
> 
> --
> http://www.apache-ssl.org/ben.html
> 
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Mime
View raw message