|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
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
 [2011-02-27 03:08 UTC] fake at example dot com
Following functions may report E_WARNING when invalid utf8 sequence detected.

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 which unfortunately got marked bogus.

Test script:
ini_set('display_errors', 1);

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

ini_set('display_errors', 0);

//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. 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-27 15:24 UTC]
-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 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]
-Status: Verified +Status: Closed -Package: *Configuration Issues +Package: Unknown/Other Function -Assigned To: +Assigned To: cmb
 [2016-10-12 14:46 UTC]
This issue has been resolved for htmlspecialchars/htmlentities as
of PHP 5.4 and for json_encode as of PHP 5.5 already.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jun 25 21:01:29 2024 UTC