httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: apache handlers (1)
Date Wed, 06 Aug 1997 18:19:13 GMT
On Wed, 6 Aug 1997, Dean Gaudet wrote:


> > 2. Adding additional phases to the module record is backwards compatible
> >    (it's not forwards compatible, but that's another matter). ANSI C is
> >    smart enought to fill in the extra slots without complaining.
> But it requires a recompile of the module... but in practice this is
> required occasionally anyhow as the api mutates.

It's always required. Any time we update MODULE_MAGIC_NUMBER, modules
stop working. add_module() checks to make sure the number compiled into
the module matches the one Apache's using. If they don't, it won't load
the module. This isn't the best of solutions, but it's the only one that
works with the current haphasard way we treat our API.

> > 4. As near as I can tell, your patch does not provide the equivilent of
> >    Dean's optimizations to eliminate NULL handlers.
> Haven't looked closely, but in theory it can do this easily.  But you have
> to dictate in the API that the register function can only be used during
> the init_module phase.  This is a reasonable requirement in my opinion ... 
> but I know others differ ... others that want to get rid of all phases! 

It's reasonable IMHO. Although I think your earlier (last month)
suggestion to add a way to turn an already-added handler on or off is a
good way to acheive both.


> > 6. As Roy has repeatedly pointed out, if we do this, there are better
> >    things we can do: Currently, handlers are only registered by content
> >    type. It would be very handy if they were also registered by method,
> >    and possibly other things. We'd need to sit down and either think of
> >    all these things (unlikely), or set up the callback functions to be
> >    extensible (more likely).
> But handlers and the other (api) methods are slightly different beasts. 
> Just slightly though. 
> What is stopping a module from setting r->handler during, say, fixups ?
> Something like this is a more general solution ... but not complete.

No, this has nothing to do with *setting* r->handler, but executing
it. The handler part of the API should work off more than just content
type/handler name. At the least, it should also function off of a

And there are other places where having an extensible method of adding
tokens to the phase function defenition would be useful. We could do
something like this:

int add_api_function(pool *p, enum api_phase phase, void *(*function)(), ...);

Then you could just add the tokens at the end. The equivilent of a simple
translate_name phase might just be:

add_api_function(p, api_translate, foo_translate, NULL);

But a handler might look something like this:

add_api_function(p, api_handle, handle_foo, "type:text/html", "method:GET",

There are other conceivable places where extensions would make sense. For

add_api_function(p, api_log, log_foo, "status:404");

Since these would be in the init phase, the extra parsing needed to
interpret the strings wouldn't matter much (they would be stored privatly
in their native formats for easy access as ints or whatever).

Actually, the current initalization phase wouldn't work for this, because
it's called once per server. On Windows, it's actually called once
per server per child. What we need is a new phase, which is called
once per start/restart. Only once. No matter what (I suppose it would get
the main server config as a parameter). All the other phases (including
the current per-ser init phase) could be added here.

You could also do things that you only want to happen once. Like forking
off a process to companion the web server, maybe. My Java servlet code
does this (, and currently I have a check for
!s->is_virtual, so it only happens once, but it'd be nice to have a
seperate phase.

-- Alexei Kosut <>

View raw message