[
https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021626#comment-13021626
]
Erick Lichtas commented on NET-354:
-----------------------------------
Calling close on the client side appears to be notifying the server of an ssl
shutdown. The EFT server i was testing against appears to be having issues
when this notification is sent, whereas works, when we do not call
socket.close() and simple discard the ssl socket wrapper. Other server's such
as ProFTPd seem to leave it up to the client to shutdown ssl which works great
with the patch applied to Commons NET. There also appears to be a potential
timing issue if both the server and client initiate the ssl shutdown.
My question is, what is the correct behavior? It makes sense that it be left
up to the client to shutdown the SSL as the CCC is initiated by the client.
I'm curious if CuteFTP (which is made by the same company as the EFT server)
works with ProFTPd. I'm guessing it will not.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command
> Channel). Proper behaviour is to close SSLSocket, but keep underlying
> connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on
> line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting
> _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the
> same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
