Wireshark-bugs: [Wireshark-bugs] [Bug 12958] Wrong JSON format returned by new -T json feature
Comment # 12
on bug 12958
from Fayçal NOUSHI
Harris, to answer your question about the need for key uniqueness.
Here's an answer by "user454322" on stackoverflow.com
<quote>
The JSON Data Interchange Format (ECMA-404) doesn't say anything about
duplicated names (keys).
However, The _javascript_ Object Notation (JSON) Data Interchange Format)
(RFC7159) says:
The names within an object SHOULD be unique.
In this context should must be understood as specified in RFC 2119
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.
RFC 7159 explains why unique names (keys) are good:
An object whose names are all unique is interoperable in the sense
that all software implementations receiving that object will agree on the
name-value mappings. When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the
object, and some implementations report all of the name/value pairs,
including duplicates.
JSON parsing libraries have been observed to differ as to whether or not
they make the ordering of object members visible to calling software.
Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences.
</quote>
here's a link to another answer about the same subject:
http://stackoverflow.com/questions/17063257/how-to-generate-a-json-object-dynamically-with-duplicate-keys/19927061#19927061
On Python implementation, keys get overwritten. On Java, they seem to raise
exceptions... some other library might just accept duplicate keys, who knows...
Anyway, having duplicate keys may result in unexpected behaviors, depending on
the library used.
I think there are a few categories for the duplicate key issue:
- key for redundant information: ip.addr for example. This information is
present in both ip.src and ip.dst. This kind of info can simply be removed
- key that need to keep its position in regards to other keys on the same
level. Such as tcap and gsm_map layers/keys. Nesting may be an option here.
- keys that do not need to have that position kept. These duplicate keys can
have their values transformed into an array.
Anyway, I think there's a need for a transformation layer before outputting to
JSON
You are receiving this mail because:
- You are watching all bug changes.
