Bug #47494 [Bgs]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494edit=1
ID: 47494
Updated by: ras...@php.net
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
This isn't a logic error. The idea is to prevent a user-triggered
information
leak by not showing this error to the user in case a production server
is
misconfigured and running with display_errors turned on.
Previous Comments:
[2011-05-02 14:48:50] example at example dot com
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
[2011-03-10 18:05:11] dtajchre...@php.net
I say this is a logic error. Bugs #54109 and #52397 also mention the
same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I
don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Invalid multibyte sequence
in argument);
}
[2011-03-10 17:37:31] pinkgothic at gmail dot com
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 a configuration variable tells that errors are shown on screen then
I
think all errors (dependent on reporting level) are shown - and not
that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
Yeah, you're not alone; but live and learn, I guess? :)
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).
Well, from my experience, people who deliberately turn display_errors on
for development except their feedback in
the browser window [*unless* they are writing for XHR], not in a log
they may also be running in parallel.
This is especially true if you have a complex application that logs
debug information from several services into one
file in a compact format - so, unless you're LOOKING for an error, you
won't spot anything. (Total sidenote, I
honestly wish I could change the log format I have to suffer... but I'm
stuck with it. Gargh.)
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.
By the time you find this closed php bug... well, if you're lucky,
you've forced your developers to have a wrapper
function you can now add a try-catch to - otherwise you can now do a
project-wide search for every call of the
function. [To be fair, I was fortunately lucky.]
Could this bug please get REOPENED as a documentation bug? I think
adding this behaviour to the documentation would
help a lot of people confused by it.
[2010-06-14 13:30:05] trueleader at gmx dot de
Why the developer of the language create a workaround for bad configured
servers and/or applications?
If a configuration variable tells that errors are shown on screen then I
think all errors (dependent on reporting level) are shown - and not that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my
Bug #47494 [Bgs]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494edit=1
ID: 47494
Updated by: dtajchre...@php.net
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
I say this is a logic error. Bugs #54109 and #52397 also mention the
same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I
don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Invalid multibyte sequence
in argument);
}
Previous Comments:
[2011-03-10 17:37:31] pinkgothic at gmail dot com
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 a configuration variable tells that errors are shown on screen then
I
think all errors (dependent on reporting level) are shown - and not
that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
Yeah, you're not alone; but live and learn, I guess? :)
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).
Well, from my experience, people who deliberately turn display_errors on
for development except their feedback in
the browser window [*unless* they are writing for XHR], not in a log
they may also be running in parallel.
This is especially true if you have a complex application that logs
debug information from several services into one
file in a compact format - so, unless you're LOOKING for an error, you
won't spot anything. (Total sidenote, I
honestly wish I could change the log format I have to suffer... but I'm
stuck with it. Gargh.)
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.
By the time you find this closed php bug... well, if you're lucky,
you've forced your developers to have a wrapper
function you can now add a try-catch to - otherwise you can now do a
project-wide search for every call of the
function. [To be fair, I was fortunately lucky.]
Could this bug please get REOPENED as a documentation bug? I think
adding this behaviour to the documentation would
help a lot of people confused by it.
[2010-06-14 13:30:05] trueleader at gmx dot de
Why the developer of the language create a workaround for bad configured
servers and/or applications?
If a configuration variable tells that errors are shown on screen then I
think all errors (dependent on reporting level) are shown - and not that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
We just lost some data, because we fill a JS confirm message on a HTML
click event with a string from a PHP language variable. Nobody knows
that we missed to utf8_encode because all developers use display_errors
on and therefor no error is shown/logged for this problem
[2009-11-20 20:24:21] s...@php.net
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
