News for hackers. Stuff that matters.
Re:I accidentally used YAML.parse instead of JSON.parse and ... by vbezhenar on Monday January 24, 2022 @01:15AM (#30054214)
I just checked YAML 1.2 and it seems that 1024 limit length on keys still in spec (https://yaml.org/spec/1.2.2/, ctrl+f, 1024). So any JSON with long keys is not compatible with YAML.
Re:I accidentally used YAML.parse instead of JSON.parse and ... by twic on Monday January 24, 2022 @05:40AM (#30055854)
The JSON specification [1] states:

> An implementation may set limits on the length and character contents of strings.

So this length limit is not a source of incompatibility with JSON.

[1] https://datatracker.ietf.org/doc/html/rfc7159#section-9

Re:I accidentally used YAML.parse instead of JSON.parse and ... by eatonphil on Monday January 24, 2022 @09:39AM (#30058103)
Wow! That makes it pretty hard to know you've generated useful JSON especially if your goal is to for cross-ecosystem communication.
Re:I accidentally used YAML.parse instead of JSON.parse and ... by forty on Monday January 24, 2022 @03:00AM (#30054699)
To be fair, any JSON implentation is going to have a practical limit on the key size, it's just a bit more random and harder to figure out :)
Re:I accidentally used YAML.parse instead of JSON.parse and ... by hvdijk on Monday January 24, 2022 @03:08AM (#30054750)
If you mean limited by available memory, then sure but that does not apply just to key size. If you mean something else, could you elaborate?
Re:I accidentally used YAML.parse instead of JSON.parse and ... by ionicgiraffe on Monday January 24, 2022 @07:18AM (#30056738)
Another reason to have a limit well below the computer's memory capacity is that one could find ill-formed documents in the wild, e.g., an unclosed quotation mark, causing the "rest' of a potentially large file to be read as a key, which can quickly snowball (imagine if you need to store the keys in a database, in a log, if your algorithms need to copy the keys, etc.)
Re:I accidentally used YAML.parse instead of JSON.parse and ... by forty on Monday January 24, 2022 @06:33AM (#30056278)
I assume JSON implementations have a some limit on the key size (or on the whole document which limits the key size), hopefully far below the available memory.
Re:I accidentally used YAML.parse instead of JSON.parse and ... by hvdijk on Monday January 24, 2022 @12:02PM (#30060435)
I assume and hope that they do not, if there is no rule stating that they are invalid. There are valid reasons for JSON to massive keys. A simple one: depending on the programming language and libraries used, an unordered array ["a","b","c"] might be better mapped as a dictionary {"a":1,"b":1,"c":1}. Now all of your keys are semantically values, and any limit imposed on keys only makes sense if the same limit is also imposed on values.
Re:I accidentally used YAML.parse instead of JSON.parse and ... by forty on Monday January 24, 2022 @02:28PM (#30062662)
Yes absolutely, in practice the limit seems to be on the document size rather than on keys specifically. That said it still sets a limit on the key size (to something a bit less that the max full size), and some JSON documents valid for a given JSON implentation might not be parsable by others, in which case the Yaml parsers are no exceptions ;)

I'm not even sure why I'm playing the devil's advocate, I hate Yaml actually :D

Re:I accidentally used YAML.parse instead of JSON.parse and ... by 01acheru on Monday January 24, 2022 @03:30AM (#30054866)
I guess it is about different implementations of some not properly formalized parts of the JSON spec.

There was also an article here some time ago but I cannot find it right now.

Re:I accidentally used YAML.parse instead of JSON.parse and ... by clcaev on Monday January 24, 2022 @05:46AM (#30055903)
1024 limit is for unquoted keys, which do not occur in JSON
Re:I accidentally used YAML.parse instead of JSON.parse and ... by tinita on Monday January 24, 2022 @01:22PM (#30061648)
Have a closer look. The 1024 limit in version 1.2 is only for implicit block mapping keys, not for flow style `{"foo": "bar"}`