On Oct 9, 10:02 am, "Simon Ask Ulsnes" <[EMAIL PROTECTED]> wrote:
>
> Data source trust issues are important to consider. It is, however,
> fairly irrelevant to the original criticism, which was related to the
> performance of parsing JSON structures using eval() in V8.
Performance is critical, particularly in a language like V8 that is
noted for its speed. It's because of the slowness of many built-in
JSON parsers that so many other implementations have appeared. Nobody
likes slow data interchange because it makes your application seem
unresponsive. On the server side any slowdown limits your scalability
too, especially when the JSON implementation is layered as in many
languages that want to avoid the dangers of direct eval(). In
addition to that, JSON tends to be selected over XML precisely because
it can be a lot faster because it's less verbose and simpler to
parse. Providing a slow JSON defeats the purpose of choosing JSON.
> I fail to see the need for an external parser just for JSON.
It wouldn't be an external parser, just a separate, machine-generated
module sitting within the V8 sources. You'd link in a Ragel compiled
state machine parser in the same way as you might link in a yacc'd
parser or a regular expression library. Once linked in, it's
internal, as much a part of the project as eval(), but without the
danger of eval().
Reinventing wheels is a waste of time, and reinventing wheels poorly
makes no sense at all. No JSON parser that you could put together in
a few weeks is likely to come anywhere close to the speed of Ragel
simply because Ragel's state machine is compiled --- it leaves yacc/
lex parsers in the dust, for example. That's no different to the
situation with Javascript implementations: they were all dead slow
until more advanced projects like V8 began to add internal
compilation. You don't do that kind of thing overnight, so a home-
grown JSON for V8 would be as slow as all those other first-generation
JSON parsers out there.
> If you are exchanging data with an
> external source over an unencrypted connection, then yes, using eval()
> is a critical bug. But there are other ways.
> Using eval() is always dangerous.
Not very useful to propose it then. ;-)
> The cases when JSON is accepted from untrusted parties are rare, though,
> but theoretically possible (most cases I'm assuming is a webserver returning
> JSON from an AJAX call, where no third party is involved).
That's back to front. The cases where JSON is accepted from untrusted
parties constitute the primary use case, since JSON is a serialization
format and hence is typically used for interchange between remote
machines, which by definition should NEVER trust each other. Just
about the only cases where JSON can be used in a trusted mode are for
private local data persistance, and even then it's highly debateable
whether it should be allowed to go anywhere near eval(). It will bite
you one day. Validation should never be an optional extra.
Morgaine.
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
