From: K. G. <kim...@gm...> - 2008-09-02 20:29:57
|
Hi Divye, On Tue, Sep 2, 2008 at 17:41, Divye Kapoor <div...@gm...> wrote: > >> > I would not advise such a commit as it atleast prevents *us* from >> > munging >> > line endings while handling text bodies. >> >> I'm not sure I understand... Are you saying it could mask bugs in >> cpp-netlib? Could you elaborate? > > As of now, we are not touching the response body given by the server. Right > now, we know that the python server is returning fewer characters of the > body than expected and we are retaining it bit for bit, allowing the test to > fail on Windows. Right. But I'm suggesting we should start from data that the Python server does not destroy, allowing the test to *succeed* on all platforms. > However, if we do need to process the body at some other > stage, say to support multipart responses, it would be helpful to retain > the test with the CRLF line endings to ensure that non-native line endings > are being processed properly by the library while handling the body. As it currently stands, the library will only ever receive LF from the Python server, no matter what the source data looks like, as some Python library strips CR from all line ends. I'm not sure what you mean by "non-native line endings", but the Python server will always return LF-only (until that bug is fixed in Python, which looks like it could take a while) so the CRLF file will only serve to test Python, not our client library... Or am I still missing something? Thanks, - Kim |