httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject How to Handle Handlers and Order Hooks (and Other Matters)
Date Sun, 31 Dec 2000 17:19:39 GMT
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

Mime
View raw message