Dan, my colleague Jim L. had this thought:

>> I think Daniel's right and that it's very prudent to avoid
permanently
>> disabling session reuse. Having an option switch for telling the FTP

>> client whether or not it may attempt to reuse sessions is a great
idea.
>> My impression was that the current options CURLOPT_FRESH_CONNECT &
>> CURLOPT_FORBID_REUSE would do this. Furthermore, the option switch
idea
>> isn't case specific to WS_FTP servers; session reuse is more likely
>> problematic with "older" implementations of FTPs.
>>
>> DET claims that the RFC does not address a standard means for session
>> reuse. Therefore, DET claims that the server implementation is not
>> flawed, since there is no measure by which one can assess the
server's
>> success or failure at implementing session reuse. I think it's safe
to
>> say that the client software implementation is not flawed either -
unless
>> the option switches mentioned above are proven to be erroneously
>> implemented. Feel free to share with Daniel.
>> -Jim

Dan, I remember trying all combinations of CURLOPT_FRESH_CONNECT &
CURLOPT_FORBID_REUSE and with each combination got the "Unknown SSL
protocol error" when connecting to the server with client and server
certificates enabled at DET.

Maybe these options are related to something else and not to the code
around line 1325 in 'ssluse'. It seems, however, that Jim's reading of
the
documentation is that they relate to the problem.

And, with regards to what you wrote:

>> Yes, it would be possible and would fit in nicely I think. It just
got
>> less important now that we know this is a server flaw. I'll see if I
get
>> some time over to add this.

I just want to say -- thank you for keeping this on your radar. I can't
say enough about how great the support for libcurl is. We're proceeding
full steam ahead with libcurl as our FTP solution.

David.
Received on 2006-08-25