Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42251 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3344 invoked from network); 14 Dec 2008 09:13:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Dec 2008 09:13:17 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 204.11.219.139 mail.lerdorf.com Received: from [204.11.219.139] ([204.11.219.139:43290] helo=mail.lerdorf.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 32/86-47862-C2EC4494 for ; Sun, 14 Dec 2008 04:13:17 -0500 Received: from [216.145.54.15] (socks3.corp.yahoo.com [216.145.54.15]) (authenticated bits=0) by mail.lerdorf.com (8.14.3/8.14.3/Debian-6) with ESMTP id mBE9DBRp028140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Dec 2008 01:13:12 -0800 Message-ID: <4944CE27.9010800@lerdorf.com> Date: Sun, 14 Dec 2008 01:13:11 -0800 User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: mike CC: PHP Developers Mailing List References: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net> <15E310EAB433466EAF996B252CBED2BB@pc> <49448D66.2030501@lerdorf.com> <28139bc0812132210p1ed94f4ds40e31ff499cf2e7@mail.gmail.com> <7463F1E1-A880-479F-9584-30FFCED6E614@gmail.com> <4944AA37.9030400@lerdorf.com> <234C8048-A00D-4AEE-A23E-5FA10EA85D6D@gmail.com> <4944AD36.7070406@lerdorf.com> <6C9F85B0-29B8-419C-8DD1-BA90135214D3@gmail.com> <4944C651.1090801@lerdorf.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Removing basic types from our JSON parser From: rasmus@lerdorf.com (Rasmus Lerdorf) mike wrote: > On Sun, Dec 14, 2008 at 12:39 AM, Rasmus Lerdorf wrote: > >> Eh? Read what you wrote there. If json wasn't pure javascript, how in >> the world would eval() work on it? > > Sorry. I guess I meant it didn't execute by itself, but needed to be > interpreted using something like eval and/or thrown into a variable > before it was useful. Otherwise it's just text. > > I'm not sure why we had to do that workaround I previously mentioned, > and I cannot find a repository with that old code, but nowadays > json_encode seems to work seamlessly for all the data we exchange > (which are strings, ints, arrays, no objects, possibly not even > booleans) and just wanted to voice off if there was any possible > incompatibility that may be introduced here. > > I'll go back in my corner now :) I thought I explained that a few times now. JSON is defined in the RFC as a subset of Javascript, so a "JSON Parser" doesn't need to have all the capabilities of the javascript parser. Things break if you pass the output of json_encode() to a JSON parser that follows the RFC to the letter. When we do json_encode(123) we spit out just: 123 or json_encode("abc") we produce just: "abc" this is obviously valid Javascript so both eval and direct injection into a script block (which is the same thing) will work fine. But the RFC says we should be wrapping either array or object notation around it. As in [123] and ["abc"] to make it valid JSON. Direct injection into will still work, of course, the only change is that foo now becomes an array with a single string element as opposed to just the string itself, so making this change will break existing javascript that relies on PHP producing unwrapped basic types. Now, in most cases when you are passing stuff around via json, you don't do that for a single value, so in most cases you end up passing an array anyway, and in that case nothing changes. -Rasmus