You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Justin SB (JIRA)" <ji...@apache.org> on 2008/02/14 00:03:08 UTC

[jira] Updated: (DIRMINA-530) Compression filter - trivial bug fix and fix for use with SSL

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

Justin SB updated DIRMINA-530:
------------------------------

    Attachment: patch-compression.diff

Patch file fixes both issues.


> Compression filter - trivial bug fix and fix for use with SSL
> -------------------------------------------------------------
>
>                 Key: DIRMINA-530
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-530
>             Project: MINA
>          Issue Type: Bug
>          Components: Filter
>    Affects Versions: 2.0.0-M2
>         Environment: N/A?  But Mac OS X Leopard (Java 1.5) does display the issue.
>            Reporter: Justin SB
>             Fix For: 2.0.0-M2
>
>         Attachments: patch-compression.diff
>
>
> The compression filter has a simple bug, where it uses limit() instead of remaining(). Where position != 0, this causes reads to exceed available data:
> -        byte[] inBytes = new byte[inBuffer.limit()];
> +        byte[] inBytes = new byte[inBuffer.remaining()];
>          inBuffer.get(inBytes).flip();
>  
> Also, when the compression filter is chained with the SSL filter, and SSL status notification is enabled, the SSL filter sends state messages through the chain.  These are not IoBuffers, but the compression filter treats them as if they were:
> +    public void messageReceived(NextFilter nextFilter, IoSession session, Object message) throws Exception {
> +    	// Ignore control messages e.g. from SSL filter
> +    	boolean compress = compressInbound && (message instanceof IoBuffer);
> +    	
> +        if (!compress)  {
> Patch file will be attached...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


SSLFilter - Restarting using startSSL

Posted by "Kok Hoor (GMail)" <ko...@gmail.com>.
Hi all,

    I am using Mina 1.1.6 (downloaded the binary release, I don't Maven too
well), and am using org.apache.mina.example.echoserver.ConnectorTest to
connect to the echo server, both setup using SSL.

I have noticed however, in the ConnectorTest.java, the following restart SSL
fails:

    connectorSSLFilter.startSSL(session);

As it will cause an 'javax.net.ssl.SSLProtocolException:Illegal client
handshake msg, 1' exception to be thrown.

I looked around the ConnectorTest and discovered that it sends a single-byte
message containing '.' before it calls startSSL. Therefore, I played around
a bit, and modified the echoserver handler to call startSSL when the '.' is
received. Amazingly it works, though I doubt I am doing this correctly. The
modified messageReceived function in EchoProtocolHandler is below:

<code>
    public void messageReceived(IoSession session, Object message) throws
Exception {
        ...
        ByteBuffer rb = (ByteBuffer) message;
        // if message received is single-byte '.', then reply with '.', and
startSSL.
        if ( rb.remaining() == 1 && rb.get() == '.' )
        {
            ByteBuffer wb = ByteBuffer.allocate(1);
            wb.put((byte)'.');
            wb.flip();
            session.write(wb).join();

            SSLHandler handler = (SSLHandler)
session.getAttribute(SSLFilter.class.getName() + ".SSLHandler");
            SSLFilter filter = handler.getParent();
            if ( !filter.isSSLStarted(session) )
            {
                log.info( "Restarting SSL" );
                filter.startSSL(session);
            }

            return;
        }
        ...
    }
</code>

My question is:

1) Is this the right way to do things?
2) If it is correct, do I need the join in 'session.write(wb).join();', or
should I not wait for the join to prevent server from not being able to
properly parse startSSL message from the client?

Thanks in advanced.

Regards,
    Kok Hoor