Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42231
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hell.ne.jp designates 84.96.92.120 as permitted sender)
To: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net>
References: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net>
Content-Type: text/plain; charset=UTF-8
Date: Sat, 13 Dec 2008 07:41:40 +0100
Message-ID: <1229150500.30719.201.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Removing basic types from our JSON parser
From: mark@hell.ne.jp (Mark Karpeles)

Le samedi 13 décembre 2008 à 03:50 +0000, Scott MacVicar a écrit :
> Hi All,
> 
> Basic types were added to our JSON decoder to PHP 5.2.1, this allows  
> one to use json_encode / json_decode on any of our scalar types. Omar  
> correctly identified #38680 as not a bug but it appears that Ilia  
> added support for this anyway violating the RFC [1]. Maybe there was a  
> reason for this but I'm not sure why?

The reason was to "make json_decode() able to decode anything encoded by
json_encode()". I believe many people may be depending on this (I saw a
few codes).

If json_decode() is made to only accept arrays/struct, the same should
be done to json_encode().

For reference I saw people use json_encode() to pass a string to
javascript into their page while avoiding bugs/XSS with stuff like
</script>.

var foo = <?=json_encode($my_string)?>;
... (yes, they maybe heared somewhere that JSON is *not* javascript, I
told 'em too).

I also saw people using json_encode/json_decode as an alternate for
serialize/unserialize.

Also, reading [2], I see about stringify "If value is an object or
array, the structure will be visited recursively to determine the
serialization of each membr or element.", this seems to assume that
"value" can be something else than "an object or array".

At least on Firefox 3.2, it is not the case.

> The problem here is that none of the other JSON parsers in any other  
> language support this and more importantly the browsers [2] which are  
> now adding native JSON support. Users are frequently expecting the  
> result from a json_encode in PHP to just work with JSON.parse() on the  
> client side. [3]

I did some tests with firefox minefield (3.2pre) :


javascript:alert(JSON.stringify({foo: "bar"}));
 => {"foo":"bar"}

javascript:alert(JSON.stringify(true));
 => Invalid argument

javascript:alert(JSON.stringify("hello world"));
 => Invalid argument

javascript:alert(JSON.stringify(["hello world"]));
 => ["hello world"]

javascript:alert(JSON.parse("[\"hello world\"]"));
 => hello world
(bug? or alert() behaviour when receiving an array?)

javascript:alert(JSON.parse("\"hello world\""));
 => Error parsing JSON

javascript:alert(JSON.parse("null"));
 => Error parsing JSON

> I have a patch for this that implements the RFC exactly and makes  
> secure json_encode only works with objects and arrays.
> 
> This would be a change for 5.3+ and we should just document in 5.2  
> that what we did was a bad idea.

I'm +0 on this, because it will break PHP code on one side, but will
break on browser stuff on the other side.

I guess making 5.3 throwing E_WARNING (or E_DEPRECATED, if someone reads
it) and removing this support in HEAD could be the default behaviour
based on how we handled most features we wanted to remove when people
started relying on those.

Anyway, maintaining two versions of the JSON parser is not something we
want (I believe) so this should be removed as soon as possible. I'm just
not sure about breaking this "features" this fast.


Mark

> [1] - http://www.ietf.org/rfc/rfc4627.txt?number=4627
> [2] - http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
> [3] - https://developer.mozilla.org/en/Using_JSON_in_Firefox
>