Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60929
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FE33EDF.2000409@lerdorf.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>
Date: Thu, 21 Jun 2012 20:39:04 +0200
Message-ID: <CAEZPtU6THsovA+hfN7tq+GiEbP5xn196cOqhNhcwTY02KJNs-Q@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, 
	Daniel Convissor <danielc@analysisandsolutions.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: pierre.php@gmail.com (Pierre Joye)

hi Rasmus,

On Thu, Jun 21, 2012 at 5:33 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app and look for that warning to get a really good idea about the
> server software being used. And yes, I know people should have
> display_errors off in production, but this case is slightly different
> because it is so universal. Other user-triggerable warnings are very
> code-dependent and there is no universal trigger string you can send to
> all PHP apps. Almost all PHP apps call htmlspecialchars() on user input
> at some point.

I have no problem to raise a warning here, but it must respect display_error.


Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org