On Mon, Oct 21, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > As long as you are doing all this work, there is one more thought that I > > > have been meaning to implement, but that I never got around to. Currently > > > perchild doesn't work with SSL, because of when the request is passed off, > > > and how SSL works. The easy solution to this, is to have the child > > > processes close the sockets for any requests that they cannot > > > handle. This will also improve the chance that a request won't be passed > > > if you have vhosts with different ports. Consider the following: > > > > > > <VHost www.foo.com:80> > > > AssignChildPerUidGid rbb rbb > > > </Vhost> > > > > > > <Vhost www.foo.com:81> > > > AssignChildPerUidGid foo foo > > > </VHost> > > > > > > There is no reason for the foo/foo child process to be listening on port > > > 80. > > > > > > Just a thought for how to get SSL to work. > > > > I actually have a patch for this already :) Although I implemented it > > only as an optimization and not because of the issue with SSL. I hadn't > > tried to do SSL yet. > > > > I'd imagine this SSL limitation will have to be clearly documented since > > it may not be obvious to everyone. > > Actually, as long as you have a patch to do this, then SSL should just > work, and no docs should be necessary. :-)
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. 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? 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. JE
