Edit report at http://bugs.php.net/bug.php?id=54109&edit=1
ID: 54109
Comment by: pinkgothic at gmail dot com
Reported by: fake at example dot com
Summary: display_errors setting causes unwanted changes in
errors reported
Status: Verified
Type: Bug
Package: *Configuration Issues
Operating System: any
PHP Version: trunk-SVN-2011-02-27 (SVN)
Block user comment: N
Private report: N
New Comment:
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 [email protected] 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).
Previous Comments:
------------------------------------------------------------------------
[2011-02-27 03:08:43] 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.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=54109&edit=1
