You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Trustin Lee (JIRA)" <ji...@apache.org> on 2007/07/12 04:41:05 UTC

[jira] Resolved: (DIRMINA-385) SSLFilter starts writing to session before filter chain is complete

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

Trustin Lee resolved DIRMINA-385.
---------------------------------

    Resolution: Won't Fix

Won't fix this issue because it's the default behavior of SSLFilter.  Instead, JavaDoc for SSLFilter has been revised.

> SSLFilter starts writing to session before filter chain is complete
> -------------------------------------------------------------------
>
>                 Key: DIRMINA-385
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-385
>             Project: MINA
>          Issue Type: Bug
>          Components: Filter
>    Affects Versions: 1.0.3, 1.1.0
>            Reporter: Chris Audley
>            Assignee: Trustin Lee
>         Attachments: SSLFilter-1.1.0.patch, SSLFilter-HEAD.patch
>
>
> The SSLFilter starts to write packets to the session as soon as it is added to the filter chain (in onPostAdd).  However, this can result in errors if a filter exists or is added before SSLFilter in the processing order. Writing to the session in onPostAdd should be considered breaking the contract between filters and the session.
> If a filter is added in the processing order before the SSLFilter, but after the SSLFilter has been added, SSLFilter will have already sent some messages that the newly added filter will never have the opportunity to process.  Any subsequent SSLFilter messages *will* be processed by the newly added filter, potentially creating inconsistencies.
> Even if the filter before the SSLFilter in processing order is added before the SSLFilter is added, having SSLFilter send messages in onPostAdd ignores the possibility that the other filter needs to send and/or receive messages before the connection is considered open by later filters in the chain.
> The specific circumstances of my problem is a web proxy traversal filter that needs to be placed in front of the SSLFilter in order to function correctly.  This filter is responsible for sending the CONNECT message to the proxy to open an outside connection before the SSL session is negotiated.  With the current behavior of SSLFilter, this is simply not possible.
> I have created a patch for SSLFilter that moves the code for initiated the handshake to sessionOpened.  This works correctly in my situation, but breaks the case where an SSLFilter is added to the chain after the connection is opened.  I try to address this by adding a conditional handshake initiation to onPostAdd only if the session is already connected.  Unfortunately, the IoSession.isConnected() method only indicates if the session hasn't been closed.  What SSLFilter.onPostAdd() needs is a way to determine if the sessionOpened event for the session has been fired.  My patches disable the code in onPostAdd() until isConnected or another method is able to provide the necessary information.

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