curl-library
a proftpd or curl bug or what?
Date: Wed, 19 Nov 2003 16:07:39 +0100 (CET)
Hi all
Please bear with me, as this is a rather long and complicated mail, but I do
need some help with some analyzing of what I've found out here.
Mr Nicolas Croiset (cc'ed now) filed bug report #843739, that shows how
libcurl fails to retrieve an FTP file on a persistant connection (it returns
CURLE_PARTIAL_FILE), if the previous transfer failed due to a missing file.
http://sourceforge.net/tracker/index.php?func=detail&aid=843739&group_id=976&atid=100976
The provided example source shows it happen in a nice repeatable fashion.
Using this, I could identify two minor problems in libcurl that were wrong but
even with these two problems fixed, I see very strange results from the FTP
server. The remote server is a ProFTPD 1.2.9 Server, which I believe is a
fairly robust, reliable and well-tested server.
Let me guide you through some VERBOSE output (when running the curlbug.c
program attached to the above mentioned bug report) and point out what I've
seen and what I can't fully understand:
* About to connect() to www.vdl.fr port 21
* Connected to server2.radio-campus.org (212.43.196.114) port 21
< 220 ProFTPD 1.2.9 Server (Serveur FTP) [server2.radio-campus.org]
> USER anonymous
< 331 Anonymous login ok, send your complete email address as your password.
> PASS curl_by_daniel_at_haxx.se
< 230 Anonymous access granted, restrictions apply.
* We have successfully logged in
> PWD
< 257 "/" is current directory.
* Entry path is '/'
> EPSV
< 229 Entering Extended Passive Mode (|||4796|)
* About to connect() to www.vdl.fr port 4796
This server is clearly modern and supports nice things such as EPSV. We
connect back to its port 4976.
* Connecting to server2.radio-campus.org (212.43.196.114) port 4796
* Connected the data stream with PASV!
> TYPE I
< 200 Type set to I
> SIZE hd_or.gif
< 213 97
> RETR hd_or.gif
< 150 Opening BINARY mode data connection for hd_or.gif (97 bytes)
* Getting file with size: 97
* Curl_read() = 97 bytes
* Curl_read() = 0 bytes
< 226 Transfer complete.
* Connection #0 left intact
ftp://www.vdl.fr:21/hd_or.gif : curl_easy_perform result = 0
This is the end of the first file retrieval, everything looks as it should.
* Re-using existing connection! (#0)
Re-using the control connection.
* Connected to server2.radio-campus.org (212.43.196.114) port 21
> CWD /
< 250 CWD command successful.
> EPSV
< 229 Entering Extended Passive Mode (|||4797|)
* About to connect() to www.vdl.fr port 4797
We connect to the next port, 4797.
* Connecting to server2.radio-campus.org (212.43.196.114) port 4797
* Connected the data stream with PASV!
> TYPE I
< 200 Type set to I
> SIZE xxxxxxx
< 550 xxxxxxx: No such file or directory
> RETR xxxxxxx
< 550 xxxxxxx: No such file or directory
ftp://www.vdl.fr:21/xxxxxxx : curl_easy_perform result = 19
The file didn't exist, and libcurl returned failure.
* Re-using existing connection! (#0)
Third file transfer attempt coming up, re-using the same connection again.
* Connected to server2.radio-campus.org (212.43.196.114) port 21
> CWD /
< 250 CWD command successful.
> EPSV
< 229 Entering Extended Passive Mode (|||4797|)
* About to connect() to www.vdl.fr port 4797
Hey, look! We get to connect to the *same* port number again only a second
or two since we last were connected to it. Isn't that fishy? And why does
it re-use the port number for the fail case and not on the successful case?
* Connecting to server2.radio-campus.org (212.43.196.114) port 4797
* Connected the data stream with PASV!
... and we connect fine to it.
> TYPE I
< 200 Type set to I
> SIZE hg_or.gif
< 213 95
> RETR hg_or.gif
< 150 Opening BINARY mode data connection for hg_or.gif (95 bytes)
* Getting file with size: 95
* Curl_read() = 0 bytes
What? On the first read from this new connection, it returns 0 bytes and thus
considers the transfer complete! This contradicts the fact that it reports
size 95...
* Closing connection #0
ftp://www.vdl.fr:21/hg_or.gif : curl_easy_perform result = 18
... error 18 is CURLE_PARTIAL_FILE, which in curl's view here is entirely
correct since the server did send a partial file!
(This output is with the latest-CVS libcurl using an additional debug output
that shows how many bytes each Curl_read() has read.)
-- Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/ [[ Do not post private mails to this email address. They won't reach me. ]] ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/Received on 2003-11-19