On Fri, 18 Aug 2006, Winslow, Dave - OJA wrote:

>> Did you compile it yourself? If so, can you try disabling the session-ID
>> cache in lib/ssluse.c:1051 to see if that is what causes this problem?
>
> Do you know if this was ever tried?

No, I don't know more on this than what's in the archive.

> There are three reasons (maybe not very good reasons) that I think
> session-ID cache might be involved.
>
> 1) Because you thought so in April of 2004 and you know things!

The reason I suggested this, as far as I can recall it, is that the re-used
session-id is just about the only thing that makes that connection somewhat
different than the first connection. Also, I don't think it actually can
re-use the session-id since it is already being in use on the control
connection. (But libcurl's session ID logic is per host name.)

> >> I have also attempted connecting from CUTEFTP (a different Windows FTP Client).
> >> This works just fine with default settings. However, the CuteFTP client has an
> >> option in the SSL section of the configuration called "Reuse cached session for
> >> data connection". When I turn this on, I get the exact same problem as I do
> >> with the Linux LFTP client.
>
> There's more in this post but the above is what seemed relevant.

Oh yes, that certainly makes the session-id theory more likely.

> Do you still think it would be worth disabling the session-ID cache in
> lib/ssluse.c:1051 and giving that a try?

I do. But not that the check for an existing session id is now on
lib/ssluse.c:1325. You should skip that check or make it always fail to find
an exiting one to re-use.

> Do you know how Holger made out with this?

Nope.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html