tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r684680 - /tomcat/tc6.0.x/trunk/STATUS.txt
Date Mon, 11 Aug 2008 14:52:16 GMT wrote:
> Author: billbarker
> Date: Mon Aug 11 02:01:39 2008
> New Revision: 684680
> URL:
> Log:
> votes
> Modified:
>     tomcat/tc6.0.x/trunk/STATUS.txt
> Modified: tomcat/tc6.0.x/trunk/STATUS.txt
> URL:
> ==============================================================================
> --- tomcat/tc6.0.x/trunk/STATUS.txt (original)
> +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Aug 11 02:01:39 2008
> @@ -119,4 +119,6 @@
>    Test the SSL socket for cert/cipher compatibility before returning it
>    +1: markt
> -  -1: 
> +  -1: billbarker The patch is horrible, since it drops connections for no good reason,
simply to 
> +                 protect against a totally brain-dead miss-configurations.  If the check
is moved into
> +                 the main except loop, then I can go for -0.
Agreed it isn't great but it was the best I could come up with. It only 
drops a single connection (if there is one during that 1ms period) 
during the connector init.

I looked at the main accept loop but the problem was I couldn't see how 
to tell the difference between this error (where we need to close down 
the connector) and the client trying to handshake with an invalid 
certificate (where we just need to drop the connection) without looking 
for key words in the exception message which just won't work with i18n.

Granted, the configuration is stupid and the error will be obvious - I 
was just trying to make it a little more graceful. The ideal would be to 
use the API to check if the combination is sensible but I couldn't see a 
way of doing that.

I'm more than happy to come up with an alternative patch if people have 
any better ideas. Failing that it will have to be a won't fix.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message