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
Received on 2014-01-26