hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera (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 12:19:50 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683003#action_12683003
] 

Asankha C. Perera commented on HTTPCORE-193:
--------------------------------------------

Hi Oleg

This happens with SSL and when a "Connection: close" response is received. Additionally, in
Linux you will not notice this, unless you put a fake breakpoint at the line receiveEncryptedData()
in SSLIOSession:isAppInputReady() to delay. But this occurs normally / and intermittently
on the Hudson machine running SunOS.

Since the channel has been closed by the peer, it returns -1, but the SSLIOSession has unencrypted
data as can be seen below, and this seems to be a case of the SSLIOSession failing to correctly
process data in the buffers.

2009-03-17 02:31:36,929 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session
sslclient-2 [interested ops: [r]; ready ops: [r]][SSL handshake status: NOT_HANDSHAKING][469][0][0][0]:
141 bytes read
2009-03-17 02:31:36,937 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session
sslclient-2 [interested ops: [r]; ready ops: [r]][SSL handshake status: NOT_HANDSHAKING][469][0][0][0]:
0 bytes read
[Raw read (bb)]: length = 26
0000: 17 03 01 00 15 F1 BB 57   48 D7 17 49 29 2F 28 8D  .......WH..I)/(.
0010: A5 AC 6D 1E F8 8A F7 C9   C7 70                    ..m......p
Padded plaintext after DECRYPTION:  len = 21
0000: 31 35 65 0D 0A C7 B4 7D   2D DC AD D1 86 99 F3 BB  15e.....-.......
0010: 0B C0 24 95 23                                     ..$.#
2009-03-17 02:31:36,938 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session
sslclient-2 [interested ops: [r]; ready ops: [r]][SSL handshake status: NOT_HANDSHAKING][443][0][0][0]:
5 bytes read
2009-03-17 02:31:36,988 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session
sslclient-2 [invalid][SSL handshake status: NOT_HANDSHAKING][443][0][0][0]: Shutdown
2009-03-17 02:31:36,989 [-] [HttpClientWorker-1]  WARN ClientWorker Unexpected response received.
HTTP response code : 200 HTTP status : OK exception : com.ctc.wstx.exc.WstxEOFException: Unexpected
EOF in prolog
 at [row,col {unknown-source}]: [1,0]

The channel closure is correctly processed by the rest of the logic, and I think the channel
alone returning -1 cannot be always/fully assumed to indicate the end of the SSLIOSession

thanks
asankha

> 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, linux.log, solaris.log
>
>
> 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


Mime
View raw message