httpd-dev mailing list archives

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


-- Alexei Kosut <>            The Apache HTTP Server

View raw message