Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57199
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F04B071.8080102@php.net>
References: <CABBJUpc7T2QZm8QiitQ0wZ5RsY=3Jwy_UERSvLT9unNYtJ1mZA@mail.gmail.com>
	<CABBJUpcVkYwU4zN0dG2b+jYkppnY9HR8wm7FV0tnmGt6ky5wQg@mail.gmail.com>
	<CABBJUpeN4iJ6mVUKEEz8qxY25zxTmwg8EigpsmxnZGz5xshMhw@mail.gmail.com>
	<4F048A03.4070408@sugarcrm.com>
	<CAH-PCH69gV88qnQ7OHhGHSt70oD7f9Z_HCFD7dfW6SmBR6z2tQ@mail.gmail.com>
	<4F04A172.7080509@sugarcrm.com>
	<CAH-PCH5BUsrXKLtk6JWCOA8d5+2DxSke3UAnbBraJyGP-YnQnA@mail.gmail.com>
	<4F04AA8E.6020701@sugarcrm.com>
	<CAH-PCH6YH3ZxH5XzEm6+gsikaHjyL-pdHyAs=OnFhWqHk0CctQ@mail.gmail.com>
	<4F04AD6D.80608@php.net>
	<CAF+90c-6XrWJnL4vOQjjPm=N=fWrMy31wHOeXGccv+KRq5DrVw@mail.gmail.com>
	<4F04B071.8080102@php.net>
Date: Wed, 4 Jan 2012 20:07:23 +0000
Message-ID: <CAKxcST9NhATxVLrOVP9h2Qy9GfuuzreeVMBtH0EqdZf7jPhytg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@php.net>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, Ferenc Kovacs <tyra3l@gmail.com>, 
	Stas Malyshev <smalyshev@sugarcrm.com>, Laruence <laruence@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: another fix for max_input_vars.
From: dragoonis@gmail.com (Paul Dragoonis)

Inline.

On Wed, Jan 4, 2012 at 8:02 PM, Rasmus Lerdorf <rasmus@php.net> wrote:
> On 01/04/2012 11:54 AM, Nikita Popov wrote:
>> On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf <rasmus@php.net> wrote:
>>> Since it is one of these remotely-triggered errors that you can't
>>> program around, it should probably be suppressed when display_errors is
>>> on. There is another precedence for this, but I am drawing a blank on
>>> where else we did this right now.
>>>
>>> -Rasmus
>> You mean like with htmlspecialchars() before PHP 5.4? Please don't.
>> It's really non-obvious to start hiding errors as soon as you enable
>> error display.
>
> But there is a very valid security concern here. People can usually run
> safely with display_errors enabled if their code is well-written. They
> can check for potential errors and avoid them. This one can't be checked
> for and you could easily write a scanner that scoured the Net for sites
> with display_errors enabled by sending a relatively short POST request
> to each one and checking for this error. And there is absolutely nothing
> people could do about this short of turning off display_errors which we
> know from experience a lot of people just don't do no matter how much we
> suggest it.

I agree with Rasmus here. A lot of people keep display_errors on, even
when they shouldn't.
It log_errors is on, it should go to the error_log, but with
display_errors it should never be sent back to the browser.

- Paul Dragoonis.

>
> The alternative is to just not have any error message at all. That
> avoids the discrepancy between the error messages with display_errors on
> and off.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>