httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject Re: apache handlers (1)
Date Wed, 06 Aug 1997 20:53:29 GMT
On Wed, 6 Aug 1997, Dean Gaudet wrote:

> 
> 
> On Wed, 6 Aug 1997, Alexei Kosut wrote:
> 
> > 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
> > method.
> 
> If you've set r->handler then you've also made the decision as to what
> will execute it.  Unless something with higher priority overrides your
> decision.

I guess. But just because you have a handler, doesn't mean that it was
set using r->handler. If I have a handler that wants to parse image/gif,
say, nowhere in the server is there anything that explictly sets that
handler. It just happens to work off of the image/gif media type.

> There are other reasons that I'd like a pre-handler, post-everythingelse
> phase.  There are cases where a module needs to do something which is only
> needed on request that's actually going to be served.  If this phase
> existed it would be trivial for modules to do things like:
> 
>     is this a content type I handle?  yeah, whack r->handler
>     is this a method I handle? yeah, whack r->handler
> 
> Yadda.  And they'd get to make the decisions in the same priority that the
> handlers are already run.

But this requires that the module determine what the proper attributes of
the request are to have the handler execute. This is actually what
happens now; handlers are supposed to check that the request is really
for them (methods and things), and return DECLINED if not.

However, this isn't obvious, and I suspect there are a lot of modules out
there that really only handle GET requests, but don't check and return
DECLINED if the method is not M_GET. By putting these checks in the
server core instead of in the module, we can enforce this sort of thing.

It also allows us to do optimizations, independent of the modules. We
could put all the handlers that do GET methods in a seperate list than
those that do not, possibly making the server more efficient. Similar
with other types of things. This could be a good idea.

[...]

> > 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.
> 
> This is exactly what the module init phase is supposed to do... fix the
> windows port.  init_modules only calls init once, with the main server.

Yeah... *sigh* You are correct. I have no clue what I was thinking. I
seem to have been very confused at some point, and somehow it stuck :)
The Windows port actually does do the correct thing here (I think).

However, in checking on this, I noticed that it does not implement
child_init or child_exit. These should be added.

-- Alexei Kosut <akosut@organic.com>


Mime
View raw message