[
https://issues.apache.org/jira/browse/DIRAPI-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRAPI-314.
--------------------------------------
Resolution: Fixed
The workaround has been replaced by a real fix. We now use a {{Future}} that is
updated when the handshake has been completed (or aborted). The {{startTLS}}
setup had to be modified for that purpose, asking for {{MINA}} to send a
{{SESSION_SECURED}} message when done, that is unblocking the {{Future}}.
Fixed with commit 61ef7c1f2ff6e60cdf1e999cc6c72fe55e72de5a
> 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)
