Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030617014330.029286b8@pop3.rowe-clan.net>
Date: Tue, 17 Jun 2003 01:53:48 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: Worker hungs ..
Cc: Cliff Woolley <jwoolley@virginia.edu>, dev@httpd.apache.org
In-Reply-To: <200306170033.56067.pyaggi@aulamagna.com.ar>
References: <Pine.LNX.4.56.0306162003360.2148@deepthought.cs.virginia.edu>
 <Pine.LNX.4.56.0306161513120.2148@deepthought.cs.virginia.edu>
 <200306162044.56223.pyaggi@aulamagna.com.ar>
 <Pine.LNX.4.56.0306162003360.2148@deepthought.cs.virginia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Perchild was designed to pass off any connection, including an SSL
connection, to another child.

If things are working right (and they admittedly probably are not), the
parent transfers the request and socket to the child.  In this case, we
cannot do that effectively because the parent is performing the SSL
negotiation.

So we effectively need an API that can keeps the raw connection
in the parent dispatcher, and won't pass off the socket in the case
that the connection filters can't be 'reproduced' in the child process.
It's still the better solution that what you were attempting to cook up,=20
but someone needs to spend time living in perchild and find the bugs=20
and strange SSL interactions before it is ready for prime time.

The other option is to transfer the entire SSL state to the child, but
that isn't generally practical.  You still are not going to be able to
do a setuid() on a per-thread basis, so your current module design
is absolutely restricted to prefork, or you will need to add some really
stringent mutexes that will probably interfere with some core code.

And I'm altogther unclear - you simply need to create a child per user,
and the current perchild design is one uid/gid pair per vhost (ideally
one would aggregate the vhosts that share a uid/gid into one process.)
Perchild never changes users because each child is running as the
appropriate user.  Now it sounds like you are writing a per-web-user=20
selection rather than per-vhost.  It certainly sounds like you are trying
to write an module but should be rolling your own auth-MPM.

Bill


At 10:33 PM 6/16/2003, Pablo Yaggi wrote:
>(I know about the popups, but I have no choice if haven=B4t got many IPs.)
>
>But if i use perchild for ssl connections it will never switch to the right=
 child,
>I mean by userid.
>
>Do I have to tune/write an MPM ? if it is so, is there any documentation
>about it, or do I have to follow the source.
>
>Pablo=20
>
>
>On Monday 16 June 2003 09:07 pm, you wrote:
>> On Mon, 16 Jun 2003, Pablo Yaggi wrote:
>> > I know the fact is mentioned in the FAQ, but I don't want that the SSL
>> > uses a certifcate valid for the virtual host, i just want that any
>> > client wich contact any of the virtual hosts to stablish an SSL
>> > connection using the default host certificate, and after that it get=
 the
>> > files hosted for that virtual host. That's why I wrote a module to
>> > translates the URL's and it doesn't care on wich virtual host is the
>> > request originated.
>>
>> Well, if you're going to have the name in the ssl certificate not match
>> the hostname that was requested, you have to be willing to accept that=
 the
>> browsers of people visiting your sites will have security warnings pop up
>> every time they visit those sites.  That's typically considered
>> unacceptable.
>>
>> I suggest you use perchild, not worker.  Then you don't have to do any
>> setuid() stuff yourself.  You should be able to tweak perchild so that
>> you can do lookups from your table so that requests end up at the right
>> worker process, and then everything should just work... all of the hard
>> stuff has already been done for you.
>>
>> PS: Yes, that would have to happen /after/ the ssl handshake, since only
>> after the handshake can the web server know which host and url were
>> requested.  But what difference does that make?
>>
>> Hope this helps,
>> Cliff