Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.0.13
-
None
-
None
Description
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 :
/** The buffer containing the message to send */ private IoBuffer buffer = IoBuffer.allocate(8);
The main class contains (with commented the Buffer content) :
// 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]
The same code, when ran on a SSL connection :
// 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]
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 :
... } else if (sslHandler.isHandshakeComplete()) { // SSL encrypt int pos = buf.position(); sslHandler.encrypt(buf.buf()); buf.position(pos); <-------------------- Wrong ! ...
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.