Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60924
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120621141241.GA25789@analysisandsolutions.com>
References: <CAF+90c-T9hPbuS3bUxnHw-+B+Y2VLu55wQJ8UrtzrcC7TiKyVw@mail.gmail.com>
	<20120621141241.GA25789@analysisandsolutions.com>
Date: Thu, 21 Jun 2012 16:25:49 +0200
Message-ID: <CAF+90c8=5C_C9wa0q-Tf0OB2vKBow2PH8Nqu5n2SUm=xU1gKgQ@mail.gmail.com>
To: Daniel Convissor <danielc@analysisandsolutions.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: nikita.ppv@googlemail.com (Nikita Popov)

On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
<danielc@analysisandsolutions.com> wrote:
> Hi Nikita:
>
>> PHP <=3D 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> =A0* A warning is thrown, but only if display_errors=3Doff
>
> So the warning is put into the error log? =A0But only if display_errors i=
s
> off? =A0And if display_errors is on, no warning is produced?
>
> That's very counter-intuitive and un-PHP-like. =A0Someone mentioned it's =
for
> security reasons. =A0By that logic, we should get rid of all error
> messages because they all reveal some information that can be used by
> attackers.

Yes, I agree with this, but other people thing differently about it ;)

Personally I'd actually remove the warning completely with the return
false behavior. The return value makes clear that there was an error
and json_last_error() can be used to determine what exactly went
wrong. The warning seems redundant in this case and could actually
make the use more complicated.

Nikita