[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[iaik-ssl] A Problem with SILK 3.0 HTTPS on MAC OS.... And a Fix!

Howdy folks,

I have found a problem when using HttpsURLConnections on an Apple MAC.

The problem exists when a HttpBasicConnection Object (Which in the release
version of SILK 3.0 is obfuscated to the class 'f') already exists for a
server, and the socket that belongs to the HttpBasicConnection is already

In Windows this all works fine, but under the MAC OS the problem occurs
because of 'when' the HttpBasicServer recogises that the socket is dead and
that the HttpBasicConnection needs to be regenerated.

In Windows, the HttpBasicServer recognises this in one of it's http???run()
methods, when an EOFExpection occurs (Connection already closed by Host).
This causes the doRequest() method (in the HttpBasicServer) to return a
NULL. This in turn cquses the HttpBasicConnections to be markIdle(false),
which closes the socket and removes the HttpBasicConnections from the
idleConnections and basically cleans up anything to do with this
HttpBasicConnection. A brand new HttpBasicConnection is then generated for
the request. This way no HttpBasicConnections stick around and we never hit
the default connection limit of 5 connections.

However in the MAC OS the HttpBasicServer sees that the socket is dead in a
different part of the code with detremental effects.

A couple of lines earlier in the runRequest() method of the
HttpBasicServer, the getConnection() method is called. In the
getConnection() method, a call is made to find an Idle HttpBasicConnection
that matches the current requiremenrts. If one is found, (which is normally
the case when a second connect to a server occurs), a check of the
HttpBasicConnection's socket is made by calling the available() method of
the sockets input stream. If this call generates an IOException, it means
that the socket is broken, therefore the HttpBasicConnection is bad and
needs to be regenerated.

In Windows, this call to available() does not give an exception (as
metioned earlier this only happens when we try an write to the socket). On
the Mac however it does! When the IOException occurs, a break is
encountered which causes a seperate part of the getConnection() code to be
called (i.e. different to in Windows). Windows markUsed()s the
HttpBasicConnection and returns it. On the Mac however the HttpManager's
negotiateConnection() method is called which checks if a new connection can
be made. If this returns true, a new HttpBasicConnection can be made and is
returned. if negotiateConnection() returns false, it means that no more
conenctions can be made, and HttpManager's waitForConncetion() method is
called which waits for one of the currently in use HttpBasicConnection to
be closed. The problem is that using this path, the Bad HttpBasicConnection
with the broken socket never gets cleaned up!  A new HttpBasicConnection
gets generated but the old connection sticks around and appears active to
the HttpManager. So eventually after a couple of these IOExceptions in the
available() method, the HttpBasicConnections start building up, and you hit
the MAX_CONNECTION (which defaults to 5).

A consequence of this is that the HttpManagers negotiateConnection() method
eventually starts returning false because the max connections have been
reached. Therfore the HttpManager's waitForConncetion() method is called
and never returns, because none of the bad HttpBasicConnections are cleaned

I managed to fix the problem though!! By adding 2 calls in the IOExeption
block in the getConnection() method of HttpBasicServer. Here is a snippet:

   // Added these lines to clean the HttpBasicConnection

This way the HttpBasicConnection is cleaned up in the conn.markIdle(true);
The break still happens, as does the call to HttpManager's
negotiateConnection(). This however will no longer return false because of
a buildup of broken HttpBasicConnection.

Does someone at IAIK please wish to confirm this bug and also a possible
patch for the releases as I am working with a customer that wants to
realease a MAC version of their product ASAP.


Gil Peeters.

 Gil Peeters
 CANCAS I.T. (bvba)
 Willemsstraat 2
 3000 Leuven
 JAVA and Distributed Object Specialists
Mailinglist-archive at

To unsubscribe send an email to listserv@iaik.at with the folowing content: