Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <CAF+90c-T9hPbuS3bUxnHw-+B+Y2VLu55wQJ8UrtzrcC7TiKyVw@mail.gmail.com> <20120621141241.GA25789@analysisandsolutions.com> <CAF+90c8=5C_C9wa0q-Tf0OB2vKBow2PH8Nqu5n2SUm=xU1gKgQ@mail.gmail.com> <4FE33EDF.2000409@lerdorf.com> <CAL+t6cGZX5Db7L+0FAc7aCRXueE2O7A-_=NrmoTCteEWWkv-2w@mail.gmail.com> <CAF+90c-NLQhGJ+H1POirt8pcxLeGBvQ5AYiBzj7Z1UOSu+YPZw@mail.gmail.com> <4FE61E9D.5050908@sugarcrm.com>
Date: Sun, 24 Jun 2012 00:50:13 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.wgdodznfidpuyk@damnation.nl.lo.geleia.net>
In-Reply-To: <4FE61E9D.5050908@sugarcrm.com>
User-Agent: Opera Mail/12.00 (Win32)
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Sat, 23 Jun 2012 21:53:01 +0200, Stas Malyshev <smalyshev@sugarcrm.com>  
wrote:

> Hi!
>
>> The warning for invalid UTF-8 stays intact and is thrown also with
>> display_errors = On. If this behavior is undesired this can be remedied
>> later.
>
> Must we discuss it 1000 times anew? There was a reason why it didn't
> throw warning when display_errors is on. The reason is that it is very
> easy to feed the server configured with display_errors = on wrong JSON
> and thus force it to reveal information, and this is largely beyond the
> control of application writer.

I find this argument unconvincing.

If json_encode() is not supposed to receive badly encoded data, then it's  
the application writer's responsibility to make sure that the data is  
correctly encoded. If, on the other hand, you think that's actually not a  
error on the part of the caller to call json_encode() with badly encoded  
data (i.e., just like htmlspecialchars() -- from which I removed the  
warning removed in 5.4 --, json_encode() also accumulates the  
responsibility validating some aspects of the input), then there's no  
reason to have a warning at all.

In other words, if it's a precondition of json_encode() that the input is  
correctly encoded (and the check is just a form of safe programming), then  
there's indeed an error on the part of the application writer, if it  
isn't, then there's no reason for any sort of warning.

(By the way, I'd prefer no warning at all, both for this and for inf/NAN.  
We already can get the error from json_last_error() if we want to)

-- 
Gustavo Lopes