Re: FTP reponse timeout on upload and download (related to 1779054 bug)
Date: Wed, 19 Sep 2007 23:11:57 +0200 (CEST)
On Wed, 19 Sep 2007, autrelandes-curl_at_yahoo.fr wrote:
> I have a similar problem than the one described in
> From the last comment, its date and the CVS logs, I presume that the bug fix
> is shipped in curl 7.17.0
Yes, and there are even several new test cases that verify this.
I honestly don't see many similarities between your problem and #1779054.
They're not the same.
> I added a -ldl at the CFLAGS of the src/Makefile (by analogy with
Funny, I've never needed -ldl with my openssl installs. I figure this means we
need to extend the OpenSSL checks in configure to check if it also needs
> /usr/bin/install -c -m 644 'curl.h'
> /usr/bin/install: `curl.h' et `/home/eric/curl-7.17.0/include/curl/curl.h'
> identifient le mÍme fichier.
> but it does not seem harmful.
For us who're not overly good at French, what does it mean and why does it
happen? It looks like you're installing it to the same dir you built it in, is
that the case?
> When I download a 40Mo file from a XFB Gateway FTP server, I get the
> FTP response timeout
28 minutes, 34 seconds.
> A download of a 20 Mo file with XFB Server works fine
13 minutes, 44 seconds.
> I tried to reproduce this bug with a server of mine (ProFTPd, with
> self-signed certificate), by adding --limit-rate 30K to simulate a long
> server response, but without success
54 minutes, 37 seconds.
Is this latter 54 minute case really going through the same network hoops as
the first 28 minute case does?
This kind of behaviour is in 99.7% of all cases because you do this connection
over a firewall/NAT/router/whatever that times out "idle" connections after N
minutes and idleness and in your case I would say that N is greater than 13
and that your latter case doesn't use the same network route as your first
You should see the same problem with regular FTP as well.
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2007-09-19