Live data from Hacker News

Parsing malformed JSON

peteris.rocks

11–20 of 57 posts

Re: Parsing malformed JSON

#11
Not a python developer so I was surprised when the built-in json library has a flag allow_nan which is True by default.

Also, not invalid, but surprising / annoying (a while to debug). An empty lua table is the same as an empty lua array: {}. This causes ambiguity.

    // will print {}
    print(cjson.encode(cjson.decode('[]')))

Re: Parsing malformed JSON

#12
post #11

Not a python developer so I was surprised when the built-in json library has a flag allow_nan which is True by default. Also, not invalid, but surprising / annoying (a while to debug). An empty lua table is the same as an empty lua array: {}. This causes ambiguity. // will print {} print(cjson.encode(cjson.decode('[]')))

Another nice feature of the built-in JSON library is that you can choose what class to instantiate with the data. The default is a dict, but if you're trying to parse Avro records (or something else that cares about field order), you can change that to an OrderedDict.

Re: Parsing malformed JSON

#14
post #9

I'm hoping nobody actually does this in production. As an academic exercise it is interesting. Maybe I'm old fashioned - I'm all for flexible APIs and all, but to its point. If a customer sends rotten stuff, it should just be rejected with a 40x code. At minimum, check to make sure it is proper JSON... I know that a lot of stream processors will put it into a queue and 200 right away and then process in the backgroun…

I don't deal with such huge files. Honestly, what use case requires 900GB of JSON?

Re: Parsing malformed JSON

#15
post #9

I'm hoping nobody actually does this in production. As an academic exercise it is interesting. Maybe I'm old fashioned - I'm all for flexible APIs and all, but to its point. If a customer sends rotten stuff, it should just be rejected with a 40x code. At minimum, check to make sure it is proper JSON... I know that a lot of stream processors will put it into a queue and 200 right away and then process in the backgroun…

> Maybe I'm old fashioned - I'm all for flexible APIs and all, but to its point. If a customer sends rotten stuff, it should just be rejected with a 40x code.

In some fields, that's not an option. I do NMS engineering. If I need to set up monitoring for something, and the only source of the diagnostics I need is an endpoint that returns malformed JSON, I can't just throw my hands up and say "the data's in a shit format, I won't touch it". I'll have no choice but to get my hands dirty and parse out whatever I can because our systems need to be monitored.

I'm lucky in that the only times I had to deal with malformed JSON at this job, I was able to fix the program that was generating it because it was maintained by my team (the problem was that it was snarfing data from a database and sending it out as JSON but forgetting to escape tab characters, and unescaped tabs aren't allowed in JSON), but my luck's gonna run out some day.

Re: Parsing malformed JSON

#16
> I have no idea how something like this was generated.

It would be interesting to ask the sender how .

> If the file is small enough or the data regular enough, you could fix it by hand with some search & replace.

off course.

> But the file I had was gigabytes in size and most of it looked fine.

I suspect a faulty JSON library, it's important to figure out how it was generated so an eventual issue can be opened and the bug can be fixed.

Re: Parsing malformed JSON

#18
I wrote a library to handle (many cases) of invalid JSON, motivated by a similar experience. https://github.com/RyanMarcus/dirty-json

I'm on my phone now, but later today I'll test to see if it would have worked for the author. It's good for cleaning up JSON, but I would be weary of putting it (or anything like it) anywhere near production.

Re: Parsing malformed JSON

#19
How well do you know the sender? Because this looks like an attack, or at least a probe: something to try and crash the parser and see what response they get back, to see if you are vulnerable to some kind of heap corruption attack.

Re: Parsing malformed JSON

#20

Malformed data is a scalability problem. Unusual failure modes from coding problems to random bit flips become inevitable as the data volume approaches infinity.

But to be clear, error correction should be done at a level far lower than the parsing stage. It's usually a property of the storage medium or the firmware that accesses it.

If you have to correct for bit flips when you begin to read or parse data, it's too late.

Post reply on HN