You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2009/03/18 12:35:50 UTC
[jira] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682995#action_12682995 ]
Oleg Kalnichevski commented on HTTPCORE-193:
--------------------------------------------
Asankha,
How exactly does the problem manifest itself?
Usually if a channel does not have any input it should return 0, not -1. -1 is meant to indicate end-of-stream, which means the channel has been closed by the peer. Does SSLIOSession fail to correctly process data still remaining in the input buffer?
My concern is if we remove the check altogether SSLIOSession will no longer be able to handle situations when a connection is terminated forcibly by closing the socket without proper SSL handshaking, which is not that uncommon.
Oleg
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org