Subject: Re: hook to an API function on fork()
To: new-httpd@hyperreal.com
Date: Fri, 16 Aug 1996 22:32:15 +0100 (BST)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
In-Reply-To: <Pine.SOL.3.93.960816112045.8442A-100000@acidik.organic.com> from
 "Alexei Kosut" at Aug 16, 96 11:31:42 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID: <9608162232.aa24797@gonzo.ben.algroup.co.uk>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

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?).

Cheers,

Ben.

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

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.            Apache Group member (http://www.apache.org)