While making transfer speed tests, I've been facing a libcurl endless
loop situation: I don't know how to reproduce, since it involves server
action, but here is what happens.
 
I am downloading a file using FTP. The download is aborted (by the write
callback function returning a short count) after a certain number of
bytes have been grabbed. The server then replies:
 
426-Unable to send data to TCP/IP.
426 Data transfer ended.

Probably because libcurl has closed the data connection.

Then libcurl sends "QUIT" and expects the server response, but meanwhile
the server has closed the control connection (I don't know why... Server
crash?). Call to read() in the loop expecting the QUIT response always
returns -1 (with err = ECONNRESET: Connection reset by peer). Thus in
ftp_readresp(), res = CURLE_RECV_ERROR (line 430), keepon = FALSE (448),
code = 0 (570) because result is still CURLE_OK, *ftpcode = 0 (591) and
returns CURL_OK (598) --> loops forever.

I've tried to look at the ftp_readresp() procedure and it seems there is
some confusion between the "result" procedure variable (that stays set
to CURLE_OK) and the "res" block variable (defined line 423), that is
set to CURLE_RECV_ERROR. However, I don't feel comfortable enough with
this code to provide a patch.

Environment info:
Client: XP + cygwin
Server: OS/400
Curl cvs version + os400 server patch.
Received on 2009-08-20