commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leif John Korshavn (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NET-354) FTPSClient not properly supporting CCC and PROT P
Date Thu, 14 Apr 2011 08:14:11 GMT

    [ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019719#comment-13019719
] 

Leif John Korshavn commented on NET-354:
----------------------------------------

Sebb, where exactly is the current trunk source for 3.0-SNAPSHOT?
I checked out anonymously from http://svn.apache.org/repos/asf/commons/proper/net/trunk commons-net
but I can't seem to find my patch applied here.... Also, this looks like even older than 2.2,
perhaps 2.0...
Found the URL at http://commons.apache.org/net/source-repository.html

I have also requested a trial version from Globalspace of the same FTP server that Erick uses.


But I do believe I can see why this is failing for Erick.

FTPSClient._connectAction_:
    protected void _connectAction_() throws IOException {
        // Implicit mode.
        if (isImplicit) sslNegotiation();
        super._connectAction_();
        // Explicit mode.
        if (!isImplicit) {
            execAUTH();
            sslNegotiation();
        }
    }

This code initializes an implicit FTPS socket pretty much in the same way it does for explicit,
but notice that super._connectAction_ comes AFTER implicit sslNegotiation. This means that
all initialization of the socket in superclasses, is done on the SSLSocket, not on the underlying
socket.
This could have consequences later on, when re-establishing a plain socket. I will investigate
further.



> 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

Mime
View raw message