[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020204#comment-13020204 ]
Leif John Korshavn commented on NET-354: ---------------------------------------- @Sebb: Yes, indeed you are right, the patch is present. I guess I stumbled a bit when clicking around in my IDE. I am still waiting for Globalspace to accept my request for a trial version of their product. According to their online doc, it seems as allowing CCC is a configurable option on the server independent of explicit/implicit FTPS. > 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