Am 26.01.2014 14:33, schrieb Steve Holme: > We had the same problem in the IMAP, POP3 and SMTP tests - and what we have > done there is to include CRLF in the data lines of the data section. With > your proposed fix we could do the same for those protocols so that the > correct line ending don't need to be included in the data section of the > test specification.
As far as I understand it, changing the data section to [CR][LF] would invalidate the FTP tests on Unix systems, since there the LISTing output should be converted to [LF]. > We might want to consider extending the fix even further as well... Rather > than simply fixing up the relevant places that call sendcontrol() or > senddata() we put the fix into those functions instead. As you already said, I am not sure if putting the code into these functions is sufficient since they do also handle binary data. > Modifying these functions to automatically include the line ending if it > wasn't specified and correct it if it was would mean that this sort of thing > wouldn’t happen in the future ;-) As senddata() can contain binary data we > would have to take than into consideration. I personally do think that we should take care of the correct line ending outside of these functions, since there might be protocols that actually do send text data with [LF] line-endings, even on Windows. However we would have to catch all these places in order to fix them, but that should be easier once the changes I proposed are merged into the test suite, because they improve the visibility of these mistakes by reversing the direction of the line-ending conversions. Having said all that, I am still open to any approach that improves the detection of invalid line-endings on Unix and Windows at the same time. Best regards, Marc ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
