commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leif John Korshavn (JIRA)" <>
Subject [jira] [Commented] (NET-354) FTPSClient not properly supporting CCC and PROT P
Date Wed, 13 Apr 2011 19:42:05 GMT


Leif John Korshavn commented on NET-354:

Interesting case. Are you sure it really is the client that closes the connection with an
exception? Could it be the server refusing to process clear text commands, and hence shutting
the connection down.
Is CCC really supported in implicit mode? In my mind, implicit mode is an "encrypted only"
channel from start to end with even a dedicated port number.
The chapter "Scope of use" in this article confirms my opinion:
Erick, I believe you when you say that CCC works for the subsequent commands when not explicitly
closing down the SSLSocket, I merely want to point out that this may be a gray area with regards
to how specific the specs/rfcs are. You do know that explicit mode is the recommended mode?

Unfortunately, I am not able to run your test code, as I only use the FTPS client against
a FTP Server on IBM Mainframe, supporting only explicit mode and with rigid corporate firewalls
between me and it. The code with the patch I submitted is in daily use in test, the application
will go live in May.

I am also afraid of simply discarding the SSLSocket object, as this in a long running server
could lead to a significant leakage of resources/open files (I might be wrong, but...)

> 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