httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wilson <and...@aaaaaaaa.demon.co.uk>
Subject Re: hook to an API function on fork()
Date Fri, 16 Aug 1996 19:20:36 GMT
Alexei:
> On Fri, 16 Aug 1996, sameer wrote:
> 
> > 	I see a need for an additional API function hook..
> > 
> > 	When a new server is forked, I need to call a function,
> > immediately after said fork. Namely I need to connect to a UNIX domain
> > socket and I need root (or other non-webserver) privs to connect to
> > said socket. I can't connect prior to forking because I don't want all
> > the forked server processes to be using the same connection to said
> > UNIX domain socket-- they need seperate connections to this socket.
> > 
> > 	Thoughts? I'm probably going to have to patch http_main.c
> > because I need this soon, but an API hook would be extremely useful,
> > in particular for database applications, I think.
> 
> Yeah. This is something that's been brought up before. I think for 2.0
> we're going to add three or four new API hooks. This one, for sure, I
> think. Maybe a URL->URL mapping phase, or a filename->filename one (in
> addition to the URL->filename one we have now).
> 
> But here's a thought. I've been thinking about Apache 2.0 and sfio stacked
> disciplines, and that sort of thing. And I've discovered that the Apache
> API doesn't quite work right. Let's say you want to add a protocol-level
> thingy. Fine; that works. For example, the thttpd idea of slowing down the
> response if a user has transmitted "too much" data. Just stack in a
> function in a fixup, and it'll work.

Uuuh, does the present API allow this level of control over the
rate at which information is pumped out of the server?

> But let's say you want to, for example, gzip all data. So you write a
> function to gzip data on the fly (I'm not actually sure this is possible,
> but bear with me). The problem is, where do you stack it in? You can't do
> it in a fixup, because then the headers would get gzipped as well, which
> isn't what you want. You want to stack it in directly after the headers
> have been sent, but before the content is.
> 
> So we'd need a new phase. The problem is that it wouldn't be all-present,
> like the current ones are. Namely, a handler is responsible currently for
> sending headers. If it calls send_http_header(), fine, that's great, but
> it doesn't have to: mod_proxy, for example. Now, we could add a phase
> that's called at the bottom of send_http_header() (about the same place
> that chunking is turned on now), which would probably work in 99% of the
> cases, but not all of 'em - sometimes it wouldn't get called, if the
> module didn't use send_http_header().
> 
> Is this okay? I'm not sure. We could split the current handler phase into
> two phases: send headers (which would be probably not be called from most
> modules - the core module would just call send_http_headers()), send body
> (which would be functionally identical to the current invoke handler
> phase), with a post-header/pre-body phase in the middle. But that wouldn't
> work well with some modules, like mod_cgi, which need to read the headers
> and the body all at once from the CGI script. And it would break existing
> modules, since the headers would get sent twice.
> 
> Thoughts?

Mmm, this sounds like the pre-send puppy I whined about a while
back, I needed it then to remove code from the fixups section of
mod_cern_meta, and wanted a 'called once per request' hook to come
into play just prior to the real data getting sent, so's I could
influence the outgoing header set.

I extended the current API to add a hook in send_http_headers which
was keyed off a 'magic type' that get shoehorned into the module's
published handler structure:

    handler_rec mod_cern_meta_extended_api_handlers[] = {
    { "BEFORE_SEND_HTTP_HEADER", add_cern_meta_data },
    { NULL }
    };

    [don't get confused by this, I'm overloading the semantics of
    handler_rec, specifically the type 'BEFORE_SEND_HTTP_HEADER'
    doesn't have anything to do with the mime type of the resource
    being requested, and using this technique the addition is
    transparent to the 'normal' operation of the server.]

My main problem was finding a way to do this that din't demand a
new slot to be set up in the 'module' structure, which would have
meant for a nasty redesign each time someone else changed the API.
And in general I regarded a hardcoded response to extending API to
be inadequate.

My current setup is moving towards allowing modules to plug themselves
into the server's API by advertising their hooks much like they
advertise handlers.  So my own modules should be gradually filling
up with code like this:

    int initialise_mod_cern_meta (<whatever>) {
        api_register_hook("BEFORE_SEND_HTTP_HEADER", add_cern_meta_data);
        api_register_hook("SOME_LOCAL_KLUDGE", foo);
    }

Of course it's worth arguing that this doesn't isolate my own gear
from AG's API changes and I may still need to repatch stuff, if
say, a change is made in the agreed 'meaning' of one of these hooks.

But I don't argue.

> -- Alexei Kosut <akosut@organic.com>            The Apache HTTP Server 
>    http://www.nueva.pvt.k12.ca.us/~akosut/      http://www.apache.org/

Ay.

ps. there may also be some mileage in making Apache to be API
neutral (ie it's just some massive library of funky routines) and
instead allow the server maintainer to build their own API spec,
from the building blocks we give them, to better suit their own
needs.  Quite what this facility would do to community standards
is open to debate.

Mime
View raw message