[EMAIL PROTECTED] wrote:
Author: billbarker
Date: Mon Aug 11 02:01:39 2008
New Revision: 684680
URL: http://svn.apache.org/viewvc?rev=684680&view=rev
Log:
votes
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=684680&r1=684679&r2=684680&view=diff
==============================================================================
--- 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
http://svn.apache.org/viewvc?rev=684559&view=rev
+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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
