[blirio]

"Whether to allow duplicate object entry names." This is interesting. I just did a test and it look like `jq` evaluates `{ "a": 1, "a": 2 }` to just `{ "a": 2 }`. I have always thought that this was invalid JSON. This mean that the order of keys in JSON do have some semantic meaning.

[ADD-SP]

The JSON RFC (https://datatracker.ietf.org/doc/html/rfc8259#page-6) doesn't require the unique entry name, and also the fact is that many parser uses the last-win strategy like serde_json.

For human, this is invalid, but many web services accepts this kind of JSON consciously or unconsciously.

I'm guessing this may have become a feature of some services and it's hard for maintainers to break this behavior. ᵕ︵ᵕ

[ithkuil]

Btw YAML would be a proper superset of JSON if it wasn't for the fact that yaml doesn't allow repeated fields while JSON is relaxed about that.

That's just a small detail though. You can for all intents and purposes out JSON objects in YAML files and I'm still puzzled while so many people fiddle with indent in helm templates instead of just using toJson

[rmetzler]

For security researchers it’s also interesting which implementations parse with first-win strategy and which allow comments (I think Ruby does this).

[scottlamb]

Interestingly, ECMA-404 says the following:

> The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax.

So it is legal JSON although not useful with a lot of concrete implementations. Maybe a way to find an exciting security vulnerability involving two parsers differing in their interpretation...

[ADD-SP]

Perhaps checking a service's behavior in response to such JSON is high on the security researcher's list of things to do that are high priority and simple.

"( – ⌓ – )