Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494 Comment by: pinkgothic at gmail 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: 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. Previous Comments: ------------------------------------------------------------------------ [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 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). ------------------------------------------------------------------------ [2009-02-25 13:48:11] j...@php.net It's intentional. If you disagree, please ask s...@php.net why it is like this (I once reverted that :) ------------------------------------------------------------------------ [2009-02-24 13:57:32] philipp dot feigl at gmail dot com Description: ------------ When using htmlspecialchars with a invalid multibyte string and using UTF-8 as encoding, there are two possible outcomes based on the "display_errors" ini setting: 1. display_errors=1 => empty string is returned 2. display_errors=0 => E_WARNING is thrown This is exactly what the code states. Can be viewed in http://cvs.php.net/viewvc.cgi/php-src/ext/standard/html.c?view=markup on line 1147 However this is VERY confusing as a developer point of view. As I have display_errors always set to "1" for debugging purposes, I never realized, one of our locale strings was corrupt, as it was just emptied out. Now in the production environment, our error handler terminates the script because of the E_WARNING beeing thrown. While both of the ways (empty string / error) are acceptable for me - because ofcourse the input string is invalid, it is very confusing to have different behaviors of PHP based on the display_errors setting. Reproduce code: --------------- echo 'a' . htmlspecialchars(substr(utf8_encode('aĆ¼'), 0, 2), ENT_QUOTES, 'UTF-8') . 'b'; Expected result: ---------------- Either 'ab' Or PHP E_WARNING However not both based on display_errors Actual result: -------------- display_errors=1 => 'ab' display_errors=0 => E_WARNING ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=47494&edit=1