php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #54109 display_errors setting causes unwanted changes in errors reported
Submitted: 2011-02-27 03:08 UTC Modified: 2016-10-12 14:46 UTC
Votes:10
Avg. Score:3.9 ± 0.8
Reproduced:8 of 8 (100.0%)
Same Version:0 (0.0%)
Same OS:4 (50.0%)
From: fake at example dot com Assigned: cmb (profile)
Status: Closed Package: Unknown/Other Function
PHP Version: trunk-SVN-2011-02-27 (SVN) OS: any
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: fake at example dot com
New email:
PHP Version: OS:

 

 [2011-02-27 03:08 UTC] fake at example dot com 
Description:
------------
Following functions may report E_WARNING when invalid utf8 sequence detected.
json_encode
htmlspecialchars
htmlentities

However, they only issue the warning if display_errors is OFF. display_errors should not dictate whether the warning is triggered. 

They behave this way because of following dumb logic in source code


if (!PG(display_errors)) {
    php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid UTF-8 sequence in argument");
}


ext/standard/html.c php_escape_html_entities_ex
ext/json/json.c json_escape_string



This is more or less a repeat of http://bugs.php.net/bug.php?id=52397 which unfortunately got marked bogus.

Test script:
---------------
ini_set('display_errors', 1);
json_encode("\xFF");
var_dump(error_get_last());

echo "-------\n";


ini_set('display_errors', 0);
json_encode("\xFF");
var_dump(error_get_last());

//these have same problem
//htmlspecialchars("\xFF", ENT_COMPAT, 'utf-8');
//htmlentities("\xFF", ENT_COMPAT, 'utf-8');

Expected result:
----------------
I expect both calls to error_get_last() should not return null. Also, I should have two entries in my error log.

Actual result:
--------------
First call to error_get_last() returns null, second call works. Only one message in error log.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-27 15:24 UTC] dtajchreber@php.net
-Status: Open +Status: Verified
 [2011-03-11 13:42 UTC] pinkgothic at gmail dot com 
See also Bug #47494.

I commented there, but reckon it might be a good idea to comment here,
as well, seeing as this bug is still open. :)

> I'm afraid this isn't just confusing, but actually punishes people
> who do it right by blindsiding them completely.
>
> Scenario:
>
>  * display_errors off
>  * an Exception-throwing error handler
>
> As far as I'm informed, this is good practise. (I acknowledge I may
> be misinformed.)
>
> However, due to this behaviour, you suddenly get application crashes
> in production without that anyone really understands why the code
> snippet is suddenly a culprit. 'But we tested it with broken UTF-8,
> why are -we- just getting empty strings? And the documentation says
> that's what we should be expecting...'
[...]
> If you've been a good developer and read the manual on
> htmlspecialchars(), you're not going to expect an error. You're
> going to expect an empty string. Unfortunately currently, nothing
> in the documentation reveals that the function results in an
> E_WARNING, either pure-log-only when display_errors is on, or
> log and trigger_error()ed when display_errors is off.

I reckon this should at the very least be a documentation error,
if this explanation from stas@php.net holds:

> The idea is to return an error but not display it (i.e. log it
> or allow custom error handlers to process it).
>
> The reason for it is that, unfortunately, people run servers in
> production with display_errors=On, and
> php_escape_html_entities_ex can be triggered from all kinds of
> code that usually doesn't produce errors, which can reveal
> sensitive information on public sites.  So we chose to go after
> lesser of two evils and not generate the error in this context.
>
> For debugging, I would suggest always logging errors and
> checking the error log, as some errors may be hard to spot in
> display anyway (especially true if your script produces
> something like JSON).
 [2016-03-25 03:11 UTC] Sicklife4life at gmail dot com 
I was not informed that by clicking appointed Topix was implementing submission two such topics my apologies I am here to learn and help where I can.
 [2016-10-12 14:46 UTC] cmb@php.net
-Status: Verified +Status: Closed -Package: *Configuration Issues +Package: Unknown/Other Function -Assigned To: +Assigned To: cmb
 [2016-10-12 14:46 UTC] cmb@php.net 
This issue has been resolved for htmlspecialchars/htmlentities as
of PHP 5.4 and for json_encode as of PHP 5.5 already.
 [2016-10-12 14:50 UTC] cmb@php.net 
Related To: Bug #68031
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Nov 22 23:01:29 2024 UTC