commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19160] New: - Default __openDataConnection does not support SSL Handshake
Date Fri, 18 Apr 2003 19:20:06 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19160>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19160

Default __openDataConnection does not support SSL Handshake

           Summary: Default __openDataConnection does not support SSL
                    Handshake
           Product: Commons
           Version: Nightly Builds
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Net
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: eschnell@nvisia.com


I have successfully developed an FTP Over SSL Extension to FTPClient by creating
a new factory and overriding _connectAction_.  However, the __openDataConnection
method needs to call server.accept() before calling isPositivePreliminary in
order for an active mode 'GET' to work properly.  It also needs to call
SSLSocket.startHandshake() on the socket returned from accept.  

I implemented a near-total override of the method to create a thread to manage
the accept call.  

if accept() is not already waiting on a separate thread, isPostivePreliminary()
will hang while the remote server attempts SSL handshaking.  

This behavior was shown with JDK 1.3.1_07 and SurgeFtp server for win2k.

            if (!FTPReply.isPositivePreliminary(sendCommand(command, arg)))
            {
                server.close();
                return null;
            }

            // For now, let's just use the data timeout value for waiting for
            // the data connection.  It may be desirable to let this be a
            // separately configurable value.  In any case, we really want
            // to allow preventing the accept from blocking indefinitely.
            if (__dataTimeout >= 0)
                server.setSoTimeout(__dataTimeout);
            socket = server.accept();

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message