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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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