commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Lichtas (JIRA)" <>
Subject [jira] [Commented] (NET-354) FTPSClient not properly supporting CCC and PROT P
Date Tue, 19 Apr 2011 15:36:05 GMT


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:
>             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:, 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:

View raw message