Pseudo-JSON with unquoted property names
david-sarah at jacaranda.org
Fri Jun 5 19:19:03 PDT 2009
Robert Sayre wrote:
> On Fri, Jun 5, 2009 at 6:57 PM, David-Sarah
> Hopwood<david-sarah at jacaranda.org> wrote:
>> Accepting unquoted names is pretty harmless from a security point of view,
>> and does not add signficant specification or implementation complexity
> JSON is a wire format that enjoys good interoperability.
> Allowing unquoted names would result in documents that break many
> implementations on json.org.
How? The ES5 JSON emitter would never produce such documents.
The only circumstance under which this could happen is if people test
some other JSON emitter only with the ES5 JSON parser, and therefore
don't notice the nonconformance in that other emitter. But those
a) negligent for only testing with one other implementation, and
for not paying attention to the JSON spec;
b) just as likely to test only with some other existing JSON parser
that accepts unquoted property names [*], and still not notice.
If it were not the case both that:
- a very large proportion of JSON parsers already accept unquoted
- and that there is evidence of pseudo-JSON causing interoperability
problems in practice,
then I wouldn't be making this proposal. In that situation, one of
the general objections that I have to Postel's liberality rule --
that it can hide nonconformance and so effectively reduce
interoperability due to the testing issue above -- would apply.
(The other objections, that it tends to increase implementation
complexity and can introduce security flaws, do not apply to this
particular set of nonconformant inputs.)
But that objection loses its force when the horse has already bolted
as far as unquoted property names being widely accepted (and "widely"
is sufficient for this argument) by other JSON parsers.
[*] such as the one that we are basing this API on, json2.js, for example.
> And it would break people using eval in
> some other langauages, but don't allow unquoted names. A more liberal
> "parseObjectLiteral" capability might be nice for a future standard.
> This would even break Firefox 3's JSON functionality (used internally
> and available to extensions).
I think I was clear enough in saying "accept but not generate".
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the es5-discuss