httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: Thoughts on a 2.0 API
Date Tue, 10 Jun 1997 23:04:04 GMT
On Tue, 10 Jun 1997, Alexei Kosut wrote:

> On Tue, 10 Jun 1997, Rob Hartill wrote:
> > At the moment I think of a httpd server as a big 'filter'. All it's
> > really doing is taking lots of different looking input and spitting
> > some output out of the other end and it is not a million miles away
> > from unix tools being "|" piped from one to the next.
> > 
> > It might be a hopeless idea in practise, but now's a good time to at
> > least discuss it as an option.
> Especially, as I said, if a user installs more than one off-the-shelf
> module that do the same thing. Two authentication modules, for
> example. If both aren't run at exactly the same phase, the server
> simply won't work correctly. It's that simple.

okay that's a reasonable concern, but I'm not convinced Apache needs
to have the phase names built-in. I'm willing to concede that it's
useful to be able to categorise a handler (we we all happy to call these
self-contained objects 'handlers' and then call a 'module' something that
contains 1 or more handlers.  ?) for the purpose of getting it invoked
at the right time. What I'm not (yet) convinced of is that Apache needs
to manage these phase names in ny way. Can we just name phases as a way
to guide config hackers on where to insert a new handler, i.e. list the
standard set of handlers and group them into named phases via annotation.

If I'm told to add this new handler into the authentication phase of
the config then is there a need for Apache to know about the phase. I
don't think there is.

> In addition, if we do want to integrate the protocol API into the
> request API - which I believe to be a good idea, see my other mail on
> this subject - then we need to have an idea of when each phase takes
> place (or at least when *certain* phases take place - open connection,
> start request, send headers, send body, end request, end connection,
> etc...) or this all falls apart.

Can you explain that. I don't understand the problem.

> Now I'm not against the module/user being able to insert functions
> into places they weren't intended, which I believe is your objection
> to named phases.

My objection to named phases being part of the API is that they impose
a fixed set of divisions. With 1.2 those divisions are inflexible and
unless you ignore their original intention to get your job done you're
stuck. If all we do is redefine the divisions then we're heading for
the same problem we had with 1.2 and the late addition of new phases (the
header parser for example). Within hours I was using it to do something
other than parse headers, why ? because it let me insert a handler at
a specific point in the request's lifecycle.

You suggest relaxing the names of phases to represent ordering rather
than functions. That's an improvement. I'd be happier with that.

I suppose I was actually defining phases (I think I called them groups) of
sorts in the way I described my nameless idea. I said that handlers
could influence others via request record flags. In practice there'd
be a DONT_AUTHENTICATE flag there somewhere that achieved the same goal
as having a named phase that terminated on the first sign of success/failure
However, I think the beauty of a nameless strategy would be that I could
insert non-auth handlers among auth handlers - they'd always activate
even when some of the auth handlers around them we're deactivated.
Overall I just think it's a lot cleaner to treat all these handlers
equally; don't have any special cases and no special phases - let
the handlers themselves determine the path a request takes.

Rob Hartill                              Internet Movie Database (Ltd)   .. a site for sore eyes.

View raw message