[
https://issues.apache.org/jira/browse/DIRAPI-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421639#comment-16421639
]
Emmanuel Lecharny commented on DIRAPI-314:
------------------------------------------
The workaround is to loop until the handshake is completed (or the timeout is
reached).
This is kind of ugly.
A better solution would be to enqueue requests at the API level, and to use a
future to regularly check if the handshake has been completed.
Ideally speaking, the SslFilter would inform the session about the handshake
completion. This is possible, it's a matter of using a listener for that
purpose. The problem is that it would be blocking.
A better solution would be to add a {{sessionSecured()}} event in the MINA
{{IoSession}}, and to wait for this event to flush the enqueued messages.
> StartTLS operation is not correctly handled
> -------------------------------------------
>
> Key: DIRAPI-314
> URL: https://issues.apache.org/jira/browse/DIRAPI-314
> Project: Directory Client API
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Fix For: 2.0.0
>
>
> Currently, the {{startTLS}} operation waits for the {{ExtendedRespose}} to be
> received to add the {{SslFilter}} into the network chain. So far, so good, as
> it's not accepting any other operation while doing that (well, it does accept
> some new request, but they will be queued).
> The problem arise when the response has been received, and once the
> {{SslFilter}} has been added : the {{SSL}} handshake starts, but as it's not
> blocking, it does not forbid other operations to be executed, and as the
> secured session may not yet established, those extra messages are going to be
> mixed with the handshake messages, leading to a closure of the connection.
> We must find a way to wait for the handshake to be completed before allowing
> other operations to be accepted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
