[
https://issues.apache.org/jira/browse/HTTPCORE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506157#comment-13506157
]
Scott Stanton edited comment on HTTPCORE-319 at 11/29/12 2:18 AM:
------------------------------------------------------------------
I have reproduced it using the head of the 4.2.x branch from shortly before you
updated to 4.2.4-SNAPSHOT. There should be no deltas relative to the 4.2.3
release other than the version number. I'll try rerunning with the official
bits, but I don't expect there to be any difference. It looks like I'll still
need to build my own copy of httpcore-contrib since that's not in the
repository.
In any case, I've attached the logging class output for the socket in question.
I don't have ssl debug output because it is simply too verbose to collect over
the timeframe needed to get it to fail. However, looking at the logs, I do see
something that looks suspicious. The very first log line is from a different
nio thread that claims to be closing http-outgoing-6, followed by the beginning
of the handshake. The final message in the log happens a day later after I
attached with the debugger to confirm that I was hitting the same line in the
busy loop:
SSLIOSession.java:370
public synchronized boolean isAppInputReady() throws IOException {
int bytesRead = receiveEncryptedData();
if (bytesRead == -1) {
this.endOfStream = true;
}
After sitting on a breakpoint at that line for long enough for the socket idle
timeout, the socket was closed normally when I resumed.
was (Author: stanton):
I have reproduced it using the head of the 4.2.x branch from shortly before
you updated to 4.2.4-SNAPSHOT. There should be no deltas relative to the 4.2.3
release other than the version number. I'll try rerunning with the official
bits, but I don't expect there to be any difference. It looks like I'll still
need to build my own copy of httpcore-contrib since that's not in the
repository.
In any case, I've attached the logging class output for the socket in question.
I don't have ssl debug output because it is simply too verbose to collect over
the timeframe needed to get it to fail. However, looking at the logs, I do see
something that looks suspicious. The very first log line is from a different
nio thread that claims to be closing http-outgoing-6, followed by the beginning
of the handshake. The final message in the log happens a day later after I
attached with the debugger to confirm that I was hitting the same line in the
busy loop:
SSLIOSession.java:370
{code}
public synchronized boolean isAppInputReady() throws IOException {
int bytesRead = receiveEncryptedData();
if (bytesRead == -1) {
this.endOfStream = true;
}
{code}
After sitting on a breakpoint at that line for long enough for the socket idle
timeout, the socket was closed normally when I resumed.
> SSLIOSession goes into a loop if the server rejects an invalid certificate
> --------------------------------------------------------------------------
>
> Key: HTTPCORE-319
> URL: https://issues.apache.org/jira/browse/HTTPCORE-319
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.2.2
> Reporter: Scott Stanton
> Priority: Critical
> Fix For: 4.2.3
>
> Attachments: log
>
>
> To reproduce:
> * Set up an SSL server that requests certificates from the client.
> * Set up a client with an expired SSL certificate.
> * Establish a connection from the client to the server using BaseNIOReactor
> and SSLIOSession.
> The server will proceed through the handshake until the client supplies its
> certificate in response to the CertificateRequest message. At this point,
> the server's certificate verification will fail and it will close the
> connection.
> The client socket will become readable due to the EOF and the
> SSLIOSession.isAppInputReady() method is called to handle the EOF. The
> bytesRead gets set to -1, which sets this.endOfStream = true. Nothing ever
> sets the session into the CLOSING or CLOSED state, so it keeps looping on the
> readable EOF event.
> I'm not sure what the best approach to fixing this should be. It appears
> that if I close the session manually with the debugger from inside
> isAppInputReady, the system proceeds normally from that point, however I
> don't know what the implications of doing that might be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
