Re: [cpp-netlib-devel] localhost_tests failures

[Dean M. B. <mik...@gm...>]

Hi Kim,

On Wed, Sep 3, 2008 at 4:29 AM, Kim Gräsman <kim...@gm...> wrote:
>
> On Tue, Sep 2, 2008 at 17:41, Divye Kapoor <div...@gm...> wrote:
>>
>> 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.
>

Actually, I wouldn't worry about this -- we're hitting a bug in a
third-party application that we so happen use in our
development/testing. It's by no means a big deal that we're hitting
that bug.

Although I understand the importance of keeping the build/test clean,
we can mark this as an expected failure in Windows+Python(2.5/2.6) --
which by no means reflects as a bug in cpp-netlib.

>> 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.
>

Not in Linux.

> 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...
>

This is in Windows only, which is not a big deal.

> Or am I still missing something?
>

I think it's all about whether we want to live with the test failure
in Windows based on a perfectly valid test that exposes a bug in
Python in Windows. In this case I think it's alright for us to live
with it -- we can mark it as an expected failure if we're in Windows.

Perhaps a patch to the test to reflect this would be very welcome. :)

HTH

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.