Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain darkrainfall.org from 208.97.132.119 cause and error)
Message-ID: <2DE90513-6422-47A6-86D8-7461EF08527F@darkrainfall.org>
To: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <97.92.08167.2B47A3A4@pb1.pair.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 18 Jun 2009 20:22:16 -0400
References: <EC.C1.58950.8F15A3A4@pb1.pair.com> <4A3A6CEE.30407@sci.fi> <97.92.08167.2B47A3A4@pb1.pair.com>
Subject: Re: [PHP-DEV] bug #48583 or display_errors saga
From: gwynne@darkrainfall.org (Gwynne Raskind)

On Jun 18, 2009, at 1:09 PM, jvlad wrote:
>>> If the bug #48583 can't be accepted through bugs.php.net, I think it
>>> makes
>>> sense to discuss it here.
>> It's not a bug but "chicken'n'egg'" issue. Errors are displayed by  
>> default
>> (IIRC) so if the ini file does not get parsed an error is outputted  
>> which
>> IS
>> --Jani
> I don't agree, absolutely.
> Settings are more important and should be parsed/loaded first.
> If any error happens before this phase is complete, they should be  
> captured
> and buffered for later processing, unless the error is fatal.
> After the settings are loaded, all buffered errors should be  
> processed and
> handled according to the settings. Nothing else.
>
> Do you see any problems with this approach? Where is the promissed
> chicken&egg issue? :)
>> really good thing. Just fix that damn ini file. :)
> Sorry, but seems you do not understand the situation.
> How would an admin fix that damn ini file if the errors are not  
> appearing in
> the log?????
> Say, I'm a hosting company admin. I install packages, php in  
> particular,
> make changes to configs, etc. I do not know what web sites are  
> running and
> do not want to see if anything related to my work appear in their  
> pages.
> Never. What steps am I supposed to do to see that php.ini contains  
> bogus #?
> Take in to account that some of the errors do not appear in the  
> output at
> all. They are crashing php because passed to the handler too early.


I have to say I agree; exposing such errors can be a potential  
security risk.

-- Gwynne