1

I'm using Json.net in a 3.5 CF setting and have a problem verifying that a string is indeed complete JSON.

I am using:

var o = JObject.Parse(incomingString);

which will return null if the JSON is incomplete - but not always. If the JSON is something "mostly formed", it will parse correctly. This simple example returns an object:

{ "Name":"Bob", "Pets":[ {"Type":"Cat", "Name":"Pudge"

but if I break the JSON elsewhere, it returns null as expected.

{ "Name":"Bob", "Pets":[ {"Type":"Cat", "Nam

With no closing brackets it seems to "assume" those brackets and returns a proper JObject, but since this JSON data is streaming in I need to verify that all brackets are matched before I process it.

In our limited sandbox, I don't seem to have any of the validation methods available on the newer APIs. Any suggestions for verifying that I have the entire JSON before I process it? Thanks.

dbc
  • 104,963
  • 20
  • 228
  • 340
hvolmer
  • 125
  • 10
  • For what it's worth, I can't reproduce this in .Net 3.5 full with Json.NET 6.0.8. I get a `JsonReaderException` thrown in both cases. – dbc May 07 '15 at 16:00
  • dbc: Doesn't surprise me. I've reported it to the folks who provide Newtonsoft.Json in the libraries we get. I expect that they need to update something! I'd love an alternative method. – hvolmer May 07 '15 at 16:03
  • Does `JavaScriptSerializer` exist in the compact framework? If you just do `new JavaScriptSerializer().Deserialize(incomingString)` it will throw an exception on malformed JSON. Also, what version of Json.NET are you using? – dbc May 07 '15 at 16:10
  • 1
    It was fixed in a commit to Json.NET on Dec 27, 2010: [Fixed JToken Load and Parse methods not checking for incomplete content](https://github.com/JamesNK/Newtonsoft.Json/commit/f32e1f53c58a8023fb647531ccafdbacc11cf4e4). Suggest updating your libraries. – dbc May 07 '15 at 16:26
  • dbc: I only see version 3.5.0.0. Not sure of the rev (or frankly how to see that in VS2008). It's included in the framework they give us, which was created over the last couple years. The latest rev I see for the 3.5 package was in 2010, so _might_ assume that it's up-to-date. – hvolmer May 07 '15 at 16:28
  • Thank you for doing my research dbc! :) I'll if I can get that in there. – hvolmer May 07 '15 at 16:40
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/77233/discussion-between-hvolmer-and-dbc). – hvolmer May 07 '15 at 17:48

2 Answers2

2

OK, it was fixed in Json.NET 4.0.1: Fixed JToken Load and Parse methods not checking for incomplete content, but your're stuck on 35r8 because that's the last version that supports the compact framework. In that case, the following static helper methods will check that the start and end depths match:

public static class Json35Extensions
{
    public static JObject ParseObject(string json)
    {
        using (var reader = new JsonTextReader(new StringReader(json)))
        {
            var startDepth = reader.Depth;
            var obj = JObject.Load(reader);
            if (startDepth != reader.Depth)
                throw new JsonSerializationException("unclosed json found");
            return obj;
        }
    }

    public static JArray ParseArray(string json)
    {
        using (var reader = new JsonTextReader(new StringReader(json)))
        {
            var startDepth = reader.Depth;
            var obj = JArray.Load(reader);
            if (startDepth != reader.Depth)
                throw new JsonSerializationException("unclosed json found");
            return obj;
        }
    }
}

Using Json.NET 3.5.8, for both your test JSON strings, the exception gets thrown, but if I fix your JSON manually there is no exception. (Note - I tested the ParseObject version but I haven't tested the ParseArray version.)

dbc
  • 104,963
  • 20
  • 228
  • 340
  • Brilliant. The JObject version works even in our "sandbox." I was worried because these guys had re-written a bunch of the .IO namespace, but it spliced in. I'll give it a work out. – hvolmer May 07 '15 at 19:34
1

I would very-frankly and very-immediately declare any such behavior to be precisely what it is: A BUG!

... and a profoundly-serious one, at that.

Any JSON-parser which actually exhibits such behavior is "catastrophically broken." You should, IMHO, immediately open a trouble-ticket with the vendor of that package, and assign it the highest possible severity.

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41