Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Canonical JSON does not specify how to handle duplicate key values #1246

Open
neilalexander opened this issue Sep 22, 2022 · 2 comments
Open
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@neilalexander
Copy link
Contributor

Different implementations have different ideas on how to handle duplicate keys in JSON. They shouldn't appear in theory, but there's nothing to stop you from doing something like:

{
  "one": 1,
  "two": 2,
  "two": 3
}

How this is handled varies between implementations (Go will take the last value, Swift will take the first etc).

We don't have anything in the spec that says how to handle this case appropriately.

(created from #1232)

@neilalexander neilalexander added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Sep 22, 2022
@richvdh
Copy link
Member

richvdh commented Sep 22, 2022

The first step in solving this is (in the absence of dropping canonicaljson altogether) is to make a decision on the "correct" behaviour here. We can then figure out how to roll it out.

To open discussion: it feels like the most "correct" thing to do is to simply forbid duplicate keys (in the same way that we forbid floats, or numbers greater than 2**53). But maybe that is a PITA to implement?

@turt2live
Copy link
Member

fwiw, RFC 8785 explictly declares duplicate keys as invalid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

3 participants