Bugs item #1779054, was opened at 2007-08-21 15:38
Message generated for change (Comment added) made by dfandrich
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1779054&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ftp
Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kris (tinker105)
Assigned to: Daniel Stenberg (bagder)
Summary: very long ftp replies confuse curl

Initial Comment:
On an upload using either the curl command line or a client using the "easy" API, if the FTP reply to the STOR command exceeds about 16K (e.g. due to a custom server including debug info), curl will stop reading it and will subsequently falsely report that the connection is dead. The rest of the long reply will be emitted (if verbose set) after subsequent commands and curl will create a new connection (to perform a 2nd transfer).

I tried to fix the problem by doubling the size of UrlState.buffer and the (BUFSIZE) limit checks in ftp_readresp and Curl_GetFTPResponse but encountered a different "reckoned dead" problem, later, after the 2nd STOR, this one emitted from Curl_retry_request.

> curl --version
curl 7.16.4 (sparc-sun-solaris2.6) libcurl/7.16.4 OpenSSL/0.9.8a zlib/1.1.3
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: Largefile NTLM SSL libz

----------------------------------------------------------------------

>Comment By: Dan Fandrich (dfandrich)
Date: 2007-08-23 17:01

Message:
Logged In: YES
user_id=236775
Originator: NO

File Added: test1006

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2007-08-23 16:45

Message:
Logged In: YES
user_id=236775
Originator: NO

I've added test case 1005 that tests many short lines from the server, and
it passes, too. However, if you shorten the reply in test case 1005 by 583
characters, then the test hangs. curl hits a boundary condition when it
truncates the long line, and ends up parsing a line with a code of
"250250", which is an unexpected code.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-08-23 13:33

Message:
Logged In: YES
user_id=1110
Originator: NO

Oh well, I found it obvious how it was a problem with a single line that
long, with multiple lines I don't exactly see how it is a problem in the
code...

Any chance you can offer me access to such a server setup to debug
against?

----------------------------------------------------------------------

Comment By: Kris (tinker105)
Date: 2007-08-23 09:22

Message:
Logged In: YES
user_id=1437892
Originator: YES

No, it isn't all one line - it's a standard "long reply" with a large
number of normal-length lines. I downloaded and tried the latest CVS
(7/23) and the problem is still there.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-08-22 07:18

Message:
Logged In: YES
user_id=1110
Originator: NO

Thanks, this is now fixed in CVS and test case 1003 was added to verify
it.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-08-22 00:37

Message:
Logged In: YES
user_id=1110
Originator: NO

Is that >16K as in one single line with only CRLF at the end of the huge
chunk?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1779054&group_id=976
Received on 2007-08-24