cURL / Mailing Lists / curl-library / Single Mail


Re: Broken libcurl FTP list parsing

From: Marc Hörsken <>
Date: Sun, 26 Jan 2014 11:44:40 +0100

Am 20.01.2014 11:21, schrieb Daniel Stenberg:
> Yes, I wouldn't be surprised. A directory listing is done in text mode
> with FTP so I'd say CRLF line endings would be expected on Windows and
> LF elsewhere.
> This is probably part of the known bug #21, "FTP ASCII transfers do
> not follow RFC959".

I think that curl actually does nothing to the FTP LIST output. actually does not send a correct FTP LISTing since it is
using [CR] for test case 100 instead of [CR][LF] in accordance with RFC959.
At least that is as for as I understand and interpret section 2.2 of
RFC959. Please correct me if I am wrong here.

I also figured that it would probably make more sense to change the test
suite to convert the expected output to Windows line-endings for
text-aware test cases instead of forcing the actual output to contain
only [LF].

And since already supported text-mode data sections, I
quickly added support for it in datacheck-section.

Attached you will find 4 patches that should improve quite a lot of the
FTP LISTing tests on Windows.
Before pushing to the git repository, I would appreciate if someone
could run them on his well-tested Unix build environment to make sure
that I did not break the tests on Unix systems.

Now we only need to figure out how to improve the remaining FTP-data and
non-FTP test cases where the curl tool automatically outputs [CR][LF]
through the Console buffer, but [LF] actually is expected since no
conversion is desired.

Best regards,

Received on 2014-01-26