Yes, this agrees with what I am seeing. I'm not sure if this is a clean
solution, but adding the following code near the bottom of
FtpDataConnection.getDataSocket() is one way to resolve the problem:
if (dataSoc instanceof SSLSocket) {
((SSLSocket)dataSoc).startHandshake();
}
}
catch(Exception ex) {
I need to read up a bit on SSL sockets in Java to be sure, but it would
appear the handshake is triggered automatically when the first byte of data
is written to the socket. The above code forces the handshake to occur
immediately after the connection is completed. Thus, even if the server
closes the connection without writing anything to the socket, the client
does not complain of a handshake error.
On 1/18/07 2:08 AM, "Dave Roberts" <[EMAIL PROTECTED]> wrote:
> It was 18/01/2007 00:27, when Clinton Foster wrote:
>
>> However, when the server tries to send
>> anything to the client on the data connection, as soon as the server closes
>> the data connection the client gets an SSL handshaking error. My theory is
>> that the handshake is not happening immediately when the client makes the
>> data connection to the server, so when the server sends the data the client
>> mistakes it for the initiation of the handshake.
>
> I've seen this behaviour, but only when the directory being listed
> is empty. When not using SSL, an empty directory listing will
> result in the data connection being opened, and then closed without
> any information being sent.
>
> In SSL mode, then connection is closed before the SSL is negotiated
> and any client will report a handshake error.
>
> The RFC is ambiguous as to what should happen in this situation, and
> although some UNIX FTP servers send a 550 response instead, I
> believe this specifically breaks the RFC.
>
> Does this tie up with what you are seeing?
