The best approach is generally to be liberal with what is accepted and
very strict with what is generated. That is the recommended philosophy
of the IETF for example, and is arguably an important part of the
Internet's success.
http://www.postel.org/postel.html
While it may seem like being strict in what is accepted would promote
others to fix their bugs, whatever benefit that may have is vastly
outweighed by the loss of greater interoperablity.
Naturally you don't want to accept stuff so loosely that it constitutes
a security hole, but for simple stuff like format/syntax that shouldn't
be an issue (as long as the parser is robust in the face of all inputs,
as it should be).
Jim
Carsten Ziegeler wrote:
Hi,
while implementing the additional json validation to the sling maven
plugin, I noticed that the current json commons module we have is very
failure tolerant.
It allows for example trailing separators, like in "{,}" or { a:"1",}
It also allows duplicate keys like in "{a:"1",a:"2"}.
I've looked at the latest code at JSON.org - the new code there at least
throws an exception for duplicate keys while it still accepts the
trailing separator.
Now the json definition is imho clearly stating that a trailing
separator is not allowed.
While I'm all for not being failure tolerant to avoid any problems with
possible other json code trying to parse this stuff, I'm not sure how we
really should handle this.
I think we should make the parsing as strict as possible (although this
might introduce incompatibilities)
WDYT?
Carsten
