hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-193) A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
Date Wed, 18 Mar 2009 11:35:50 GMT

    [ 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:


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.


> 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

View raw message