Re: Broken libcurl FTP list parsing
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.
ftpserver.pl 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
And since runtests.pl 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.
Received on 2014-01-26