Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 46206 invoked by uid 500); 21 Oct 2002 18:27:13 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 46096 invoked from network); 21 Oct 2002 18:27:12 -0000 Date: Mon, 21 Oct 2002 14:27:16 -0400 From: Johannes Erdfelt To: rbb@apache.org Cc: dev@httpd.apache.org, Jonas Eriksson Subject: Re: [patch] perchild MPM bug fixes (+ open problem) Message-ID: <20021021142716.Q32760@sventech.com> References: <20021021141400.P32760@sventech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rbb@apache.org on Mon, Oct 21, 2002 at 02:21:56PM -0400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, Oct 21, 2002, rbb@apache.org wrote: > On Mon, 21 Oct 2002, Johannes Erdfelt wrote: > > Perhaps I misunderstood. The patch I had developed (which is broken > > because of the problems with the accept lock) just didn't listen on the > > socket if it has no chance of answering the query itself. > > > > That's what I thought you meant, but reading what you said again I may > > have misunderstood. > > Nope, that's exactly what I meant. (see below) > > > Did you mean closing the client socket or the listening socket? Wouldn't > > closing the client socket just cause the client to treat it as an error? > > Just close the listening socket in the child_init phase of the > module. You want to do this before you start accepting requests. You > could also do this by just removing the socket from the accept array. The > reason I like having the child close the socket, is that it eliminates > a potential bad config. > > Consider the case where an admin configures the server to listen on > www.foo.com:8080, but he never assigns a child process to listen to that > port. If you just don't accept the connections, the user will hang > forever. If every child process, however, actively closes the sockets > that it can't serve, then the client won't even be able to connect. That's a good point too. > > What I was thinking was to add an artificial limitation that you can't > > share an IP:port pair across two different uid/gid's since that's the > > only case you want to pass a connection. > > That limitation should already exist, although it may not. That limitation doesn't exist either in the documentation or in the implementation. I figured that was part of the point of connection passing. I know it's also useful for passing between the siblings for a particular uid/gid also, but why not just require 1 child per uid/gid and then not worry about connection passing at all? JE