Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: larry at garfieldtech dot com
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 bug should be reopened, not just documented. Haven't we learned
our lesson with magic_quotes and its ilk? Designing PHP to try and save
the user when the user does something stupid always backfires. Always.
MySQL has the same problem, and it backfires there, too.
The current logic is simply backward. "When display_errors is on, you
get all errors except from this function. When display_errors is off,
you get no errors except from this one function." There is no logical
reason for that.
I'm working on a project that has been stalled for over a week while we
try to figure out what's wrong with the character encoding configuration
on our production server, only to realize that the data is (probably)
bad but we didn't know it because of this bug.
This is a bug and should be fixed, not simply documented as dumb.
If a production server is misconfigured, that's not the job of the
language to fix. All that does is, as another commenter noted, punish
those who configure their servers properly. If anything, it is a
security hole for people who DO configure their server properly by
turning off display_errors, as then these strings would get echoed in
production. How is that helpful to anyone?
Previous Comments:
[2011-05-03 17:48:02] pinkgothic at gmail dot com
Could this bug please get REOPENED as a documentation bug
then? As already stated, the absence of the information in
the documentation can be crippling for people who do things
-right-. (Admittedly right now "htmlspecialchars" has my
comment on the subject, but that's hardly official...)
(Sidenote: You might also want to close Bug #54109 as bogus
for consistency.)
[2011-05-03 17:33:35] ras...@php.net
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.
[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
