[jira] [Resolved] (DIRMINA-1029) The sent buffer is reset to its original position when using the SSL Filter after a session.write()

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny resolved DIRMINA-1029.
----------------------------------------
    Resolution: Fixed

Should be fixed with http://git-wip-us.apache.org/repos/asf/mina/commit/a42871a7, http://git-wip-us.apache.org/repos/asf/mina/commit/44b58469 and http://git-wip-us.apache.org/repos/asf/mina/commit/c69999b9

> The sent buffer is reset to its original position when using the SSL Filter after a session.write()
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRMINA-1029
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-1029
>             Project: MINA
>          Issue Type: Bug
>    Affects Versions: 2.0.13
>            Reporter: Emmanuel Lecharny
>             Fix For: 2.0.14
>
>
> Last night, I played around one of our test, adding a {{SSL}} version of it. It's basically a {{TcpServer}} and a {{TcpCLient}}, which sends a message N times.
> The TCP version uses a buffer :
> {noformat}
>     /** The buffer containing the message to send */
>     private IoBuffer buffer = IoBuffer.allocate(8);
> {noformat}
> The main class contains (with commented the Buffer content) :
> {noformat}
>         // HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 00 00 00 00 00]
>         client.buffer.putLong(client.counter.getCount());
>         // HeapBuffer[pos=8 lim=8 cap=8: empty]
>         client.buffer.flip();
>         // HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 00 00 01 86 A0]
>         session.write(client.buffer);
>         // HeapBuffer[pos=8 lim=8 cap=8: empty]
> {noformat}
> The same code, when ran on a SSL connection :
> {noformat}
>         // HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 00 00 00 00 00]
>         client.buffer.putLong(client.counter.getCount());
>         // HeapBuffer[pos=8 lim=8 cap=8: empty]
>         client.buffer.flip();
>         // HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 00 00 01 86 A0]
>         session.write(client.buffer);
>         //HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 00 00 01 86 A0]
> {noformat}
> As you can see, in one case, the buffer is reset ({(SSL}}) while it is consumed on the other side(non {{SSL}}).
> It seems to be a clear bug, because we would expect the buffer to have the same value in both case, and I would expect the {{SSL}} use case to behave as the {{non-SSL}} use case.
> The fact is that the {{SSLFilter.filterWrite()}} method does :
> {noformat}
>     ...
>                     } else if (sslHandler.isHandshakeComplete()) {
>                         // SSL encrypt
>                         int pos = buf.position();
>                         sslHandler.encrypt(buf.buf());
>                         buf.position(pos);                <-------------------- Wrong !
>     ...
> {noformat}
> This buffer reset has been done a very long time ago (10 years and 9 months) to fix a problem :
> http://svn.apache.org/viewvc/directory/network/branches/api_integration/src/java/org/apache/mina/filter/SSLFilter.java?r1=169302&r2=169301&pathrev=169302
> IMO, the fix is just plain wrong. What should be done is to send back the original buffer which is always in the {{WriteRequest}} to the {{IoHandler}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)