TestServer inconsistency on "null" test

Let’s take this file: https://github.com/Azure/autorest.testserver/blob/master/swagger/body-integer.json

And the int_getNull operation. Doing a call actually return no body with a 200:

The Swagger explains that it produces “application/json”, but an empty content is not a valid JSON, meaning the Swagger does not reflect the RestAPI… Solution is to either change the testserver to put content-type “text/plain”, or to put the four characters null (valid JSON).

I try to tighten a little my deserialisation, just to start thinking about future XML parsing in Python, and this kind of details blocks me 😦

Not urgent, but should be addressed.

FYI @amarzavery

[lmazuel]

@olydis Spec update https://tools.ietf.org/html/rfc7159

A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. Implementations that generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts.

A JSON value MUST be an object, array, number, or string, or one of the following three literal names:

  false null true

[olydis]

yep I wondered WTF that empty content instead of null is all about but the hard truth is that the C# generated code has encoded null as empty string since I got here, I have no clue why this was done like that. At this point, it would be a slightly unpredicatable breaking change to change that behavior, so not sure what we can do… but I agree 100% that the testserver should test for the right thing, even if that means C# tests have to be skipped or changed