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