Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42229
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Message-ID: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net>
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Sat, 13 Dec 2008 03:50:11 +0000
Cc: Ilia Alshanetsky <ilia@prohost.org>
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  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? [...] 
	Content analysis details:   (-4.1 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.3 AWL                    AWL: From: address is in the auto white-list
Subject: Removing basic types from our JSON parser
From: scott@macvicar.net (Scott MacVicar)

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 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 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.

Scott

[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