AOLserver

Logged In: YES
user_id=21885

Bruno Mattarollo confirms that the latest nsopenssl patch
makes the problem no longer reproducible on his test system
where he was previously able to reliably reproduce the issue
of nsopenssl connections using up 100% CPU.

Patches to AOLserver 4.1.0a (HEAD), 4.0.8a
(aolserver_v40_bp branch) and nsopenssl 3.0 beta (HEAD)
have been commited. Will be part of nsopenssl v3_0beta22
tag.

Closing this ticket.

Logged In: YES
user_id=21885

I've gone through and cleaned up nsopenssl and am attaching
the patch dated 20040824 to this ticket.

This, coupled with the version-specific patches for
AOLserver, should fix the 100% CPU utilization issue folks
have been seeing. The root cause (from what I could tell)
was that the connection was flagged for HTTP Keep-Alive,
but in the case where the peer closed the connection
(hit "stop" in the browser before the response was fully sent),
the driver was returning the (dead) connection for keep-alive
when it shouldn't have.

Logged In: YES
user_id=21885

Small bug in the first 4.0.8a patch causes the server to not
respond to requests at all -- oops. Uploading corrected
patch dated 2004/08/23.

Logged In: YES
user_id=21885

Attaching proposed fix against 4.0.8a (aolserver_v40_bp
branch) which will correct the issue described in my comment
dated 2004-08-20 15:39. It also resolves another bug where
a non-"async" driver (such as nsopenssl) doesn't properly
close the connection from ConnRun() when a malformed HTTP
request is received.

Logged In: YES
user_id=21885

Attaching proposed fix against HEAD for 4.1.0a. Not
completely happy with it and I'm not even sure setting
sockPtr->state = SOCK_CLOSEWAIT is the right thing to do,
but it does fix the bug.

Logged In: YES
user_id=21885

This crash bug does not exist in the 4.0.x code, fortunately.

However, there's another "bug" in the 4.0.x code, relating to:

nsd/driver.c:

1488 if (e == s) {
1489 /* Look for a blank line on its own prior to
any "real"
1490 * data. We eat up to 2 of these before
closing the
1491 * connection.
1492 */
1493 if (bufPtr->length == 2 && e[0] == '\r' && e
[1] == '\n') {

Using "telnet" to test nssock, and "openssl s_client" to test
nsopenssl, I found that hitting <enter> in telnet sends
a "\r\n" while "openssl s_client" sends just "\n". So, on 4.0.x
and an nsopenssl connection, you can send as many blank
lines as you want ...