5 ms·
Moving to something else that JSON for this kind of thing is reasonable given the issues with parsing JSON which can cause 2 implementation to interpret it in 2
by forty 4mo ago
Moving to something else that JSON for this kind of thing is reasonable given the issues with parsing JSON which can cause 2 implementation to interpret it in 2 different ways.
https://seriot.ch/security/parsing_json.html https://seriot.ch/security/parsing_json.html
- camgunz 4mo agoCBOR has other ways it's unsuitable; the spec has a whole section about it: https://datatracker.ietf.org/doc/html/rfc9052#name-cbor-encoding-restrictions https://datatracker.ietf.org/doc/html/rfc9052#name-cbor-enco...
- Asmod4n 4mo agoCOSE was invented to solve that gap wasn’t it.
- throwaway2037 4mo agoThis is a great blog and an incredible piece of research. Re-reading again today, makes me think of Emil Stenström's recently effort to use an LLM to write an HTML5 parser in pure Python [1] using the official HTML5 spec and their test cases. [2] Later, Simon Willison used an LLM to convert the pure Python source to JavaScript. [3] It seems reasonable to ask an LLM to write a "perfect" JSON parser given the RFC spec and massive test pack from seriot.ch. Regarding the "minefield" of JSON parsing, I used to lean on Google's Gson (Java) a lot in my early days. I thought Jackson FasterXML was "too complex". Later, I realised the mind-boggling number of configuration options was weirdly more sustainable (but more complex!), because I could carefully control each JSON parser/generator edge case. [1] https://github.com/EmilStenstrom/justhtml https://github.com/EmilStenstrom/justhtml [2] https://simonwillison.net/2025/Dec/14/justhtml/ https://simonwillison.net/2025/Dec/14/justhtml/ [3] https://simonwillison.net/2025/Dec/15/porting-justhtml/ https://simonwillison.net/2025/Dec/15/porting-justhtml/