[
https://issues.apache.org/jira/browse/DIRMINA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506337
]
Trustin Lee commented on DIRMINA-385:
-------------------------------------
I suggested a work around. I would have marked this issue as 'won't fix' or
'invalid' if I am trying to excuse something. It is still open and I didn't
apply your patch just because it breaks backward compatibility. Changing
IoSession.isConnected() to return false doesn't make sense because it's
connected at that moment. I am also not sure if this is a problem and
SSLFilter is bad yet because initiation of handshake when SSLFilter is added is
an expected behavior.
Moreover, your patch fixes the problem *only* when all filters are added in
sessionCreated(). It doesn't fix the problem you described when the filters
are added in sessionOpened() or messageReceived() handler methods in a mixed
order. It merely masks the problem in the most common use cases. No? :)
We could introduce transactional filter chain manipulation so the filter chain
calls onPostAdd after all filters are added, but it's overengineering IMO.
Let me suggest you another work around until a clear solution for this issue is
found; please do not add an SSLFilter until the handshake ends. Your proxy
filter can add SSLFilter to the chain it belongs to when it needs to be added.
> 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
> Fix For: 1.0.4, 1.1.1, 2.0.0-M1
>
> 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.
