[
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: [email protected]
For additional commands, e-mail: [email protected]
