httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: hook to an API function on fork()
Date Fri, 16 Aug 1996 21:32:15 GMT
Alexei Kosut wrote:
> 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.
> 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.

[I've been away for a week, and I'm reading mail backwards, so expect my
messages to get less and less relevant ;-)]

I don't see why this would break existing modules, since they don't actually
send the headers, do they? They just set them in a table somewhere and the core
code sends them at the right moment (or have I completely lost touch here?).



> Thoughts?
> -- Alexei Kosut <>            The Apache HTTP Server 

Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email:
A.L. Digital Ltd,           URL:
London, England.            Apache Group member (

View raw message