Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60948
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FE61E9D.5050908@sugarcrm.com>
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: Sat, 23 Jun 2012 22:34:26 +0200
Message-ID: <CAH-PCH5O+r9OTVhVh+vdDZMO5mSx9bW45tSiu=OVnu7xVjneLQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, 
	Daniel Convissor <danielc@analysisandsolutions.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff1c4f8c6dfb404c329ace5
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: tyra3l@gmail.com (Ferenc Kovacs)

--e89a8ff1c4f8c6dfb404c329ace5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrot=
e:

> Hi!
>
> > The warning for invalid UTF-8 stays intact and is thrown also with
> > display_errors =3D On. If this behavior is undesired this can be remedi=
ed
> > 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 =3D on wrong JSON
> and thus force it to reveal information, and this is largely beyond the
> control of application writer.
>
> But what I am worried about even more is getting back to that "commit
> first, discuss later" mentality. Why we have again a commit in the
> stable branch before we have a consensus decision what it should be doing=
?
>

from the side, it doesn't seems to be a consensus about having this
exception not honoring the display_errors setting.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--e89a8ff1c4f8c6dfb404c329ace5--