5 ms·

> this isn't an issue in practice. It absolutely is an issue in practice. If system A handles dupes by accepting the first and ignoring the rest, and system B

by kortex 5y ago

> this isn't an issue in practice. It absolutely is an issue in practice. If system A handles dupes by accepting the first and ignoring the rest, and system B implements last-key-wins, then that's a potential source of bugs. The system might not fully parse to a map. It may, for example, do string-level modification of json strings. Is that disgusting and wrong? Yes. Have I seen it in prod? Also yes.

throw_m239339 5y ago
> It absolutely is an issue in practice. If system A handles dupes by accepting the first and ignoring the rest, and system B implements last-key-wins, then that's a potential source of bugs. The system might not fully parse to a map. But the system shouldn't be automatically be parsing a "json map" to a map at first place: {"foo":"bar","foo":"baz","foo":"qix","fiz":"buzz"} Shouldn't be deserialized into a map. but a Array<Map<string,string>> like structure. A SAX style parser for JSON can help do that. Thus the issue is the choice of parser indeed. Not JSON.
- q3k 5y ago
  > Shouldn't be deserialized into a map. but a Array<Map<string,string>> like structure. But that's the thing: you might actually expect/want a Map<string,string>, but a malicious/broken system might emit something that cannot be deserialized into a Map<string,string>. It's then the JSON parser's/deserializer's job to figure out what to do, as the standards say to do whatever. That in turn causes different parsers/deserializers to behave differently (whatever the implementer thought makes sense), which is a source of interoperability bugs.
  - throw_m239339 5y ago
    > But that's the thing: you might actually expect/want a Map<string,string>, but a malicious/broken system might emit something that cannot be deserialized into a Map<string,string>. It's then the JSON parser's/deserializer's job to figure out what to do, as the standards say to do whatever. That in turn causes different parsers/deserializers to behave differently (whatever the implementer thought makes sense), which is a source of interoperability bugs. I disagree, people are mixing up parsing and deserializing. The JSON spec isn't at fault here. The JSON spec is only concerned with defining the parsing, not the deserialization, because obviously, a JSON array isn't a PHP array or a Ruby array, a JSON map isn't a PHP object or a Go map at first place. The problem isn't with JSON but how some JSON deserializers work. Again, a deserializer isn't a parser.
    - q3k 5y ago
      > The problem isn't with JSON but how some JSON deserializers work. That makes no observable difference to the end-user of JSON wishing to use it as an interchange format. The standard might as well be perfect, but if nearly all of its implementations (yes, extending that into deserialization, not just parsing - because that's how most people use JSON!) are problematic, then the standard is effectively also problematic. This is why I also always include Python's broken implementation in my JSON rant - it's not indicative of the standard(s) being bad, but the ecosystem being bad.
      - throw_m239339 5y ago
        > That makes no observable difference to the end-user of JSON wishing to use it as an interchange format. The standard might as well be perfect, but if nearly all of its implementations (yes, extending that into deserialization, not just parsing - because that's how most people use JSON!) are problematic, then the standard is effectively also problematic. This is why I also always include Python's broken implementation in my JSON rant - it's not indicative of the standard(s) being bad, but the ecosystem being bad. Yes it does makes a difference to the end user. Otherwise why single out JSON? XML or YAML would suffer from the exact same issue. Deserializers are an anti-pattern if they don't follow a strict schema. The problem again isn't the JSON spec, it's some deserializers making assumptions about JSON types. In practice data have specs and schemas so JSON/XML/... payloads should also have schemas.
  - dragonwriter 5y ago
    > But that's the thing: you might actually expect/want a Map<string,string> Yes, but that's not the semantics of a bare JSON object; if you want the ability to commubicate that you intend that, then you use a schema language like JSON schema, which lets you say that the JSON map in this element doesn't allow duplicate keys and requires the values to be strings, at which point tools that read the schema language no it is safe to deserialize as Map<string, string>.
nuerow 5y ago
> It absolutely is an issue in practice. It really isn't. At most, it's a problem caused by picking a broken implementation that doesn't meet your needs, but that's a self-inflicted problem, not a JSON problem.

by kortex 5y ago

throw_m239339 5y ago

> It absolutely is an issue in practice. If system A handles dupes by accepting the first and ignoring the rest, and system B implements last-key-wins, then that's a potential source of bugs. The system might not fully parse to a map. But the system shouldn't be automatically be parsing a "json map" to a map at first place: {"foo":"bar","foo":"baz","foo":"qix","fiz":"buzz"} Shouldn't be deserialized into a map. but a Array<Map<string,string>> like structure. A SAX style parser for JSON can help do that. Thus the issue is the choice of parser indeed. Not JSON.

q3k 5y ago
> Shouldn't be deserialized into a map. but a Array<Map<string,string>> like structure. But that's the thing: you might actually expect/want a Map<string,string>, but a malicious/broken system might emit something that cannot be deserialized into a Map<string,string>. It's then the JSON parser's/deserializer's job to figure out what to do, as the standards say to do whatever. That in turn causes different parsers/deserializers to behave differently (whatever the implementer thought makes sense), which is a source of interoperability bugs.
- throw_m239339 5y ago
  > But that's the thing: you might actually expect/want a Map<string,string>, but a malicious/broken system might emit something that cannot be deserialized into a Map<string,string>. It's then the JSON parser's/deserializer's job to figure out what to do, as the standards say to do whatever. That in turn causes different parsers/deserializers to behave differently (whatever the implementer thought makes sense), which is a source of interoperability bugs. I disagree, people are mixing up parsing and deserializing. The JSON spec isn't at fault here. The JSON spec is only concerned with defining the parsing, not the deserialization, because obviously, a JSON array isn't a PHP array or a Ruby array, a JSON map isn't a PHP object or a Go map at first place. The problem isn't with JSON but how some JSON deserializers work. Again, a deserializer isn't a parser.
  - q3k 5y ago
    > The problem isn't with JSON but how some JSON deserializers work. That makes no observable difference to the end-user of JSON wishing to use it as an interchange format. The standard might as well be perfect, but if nearly all of its implementations (yes, extending that into deserialization, not just parsing - because that's how most people use JSON!) are problematic, then the standard is effectively also problematic. This is why I also always include Python's broken implementation in my JSON rant - it's not indicative of the standard(s) being bad, but the ecosystem being bad.
    - throw_m239339 5y ago
      > That makes no observable difference to the end-user of JSON wishing to use it as an interchange format. The standard might as well be perfect, but if nearly all of its implementations (yes, extending that into deserialization, not just parsing - because that's how most people use JSON!) are problematic, then the standard is effectively also problematic. This is why I also always include Python's broken implementation in my JSON rant - it's not indicative of the standard(s) being bad, but the ecosystem being bad. Yes it does makes a difference to the end user. Otherwise why single out JSON? XML or YAML would suffer from the exact same issue. Deserializers are an anti-pattern if they don't follow a strict schema. The problem again isn't the JSON spec, it's some deserializers making assumptions about JSON types. In practice data have specs and schemas so JSON/XML/... payloads should also have schemas.
- dragonwriter 5y ago
  > But that's the thing: you might actually expect/want a Map<string,string> Yes, but that's not the semantics of a bare JSON object; if you want the ability to commubicate that you intend that, then you use a schema language like JSON schema, which lets you say that the JSON map in this element doesn't allow duplicate keys and requires the values to be strings, at which point tools that read the schema language no it is safe to deserialize as Map<string, string>.

nuerow 5y ago

> It absolutely is an issue in practice. It really isn't. At most, it's a problem caused by picking a broken implementation that doesn't meet your needs, but that's a self-inflicted problem, not a JSON problem.