Edit report at https://bugs.php.net/bug.php?id=47494&edit=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: Not a bug -Type: Bug +Type: Feature/Change Request Package: Strings related Operating System: CentOS5 PHP Version: 5.2.8 Block user comment: N Private report: N New Comment: This really isn't a bug. I do agree that the approach isn't ideal, but we shouldn't throw warnings on bad input here because htmlspecialchars() is explicitly designed to clean up bad input and it is run directly on user data most of the time. In order for someone to avoid this warning they would need to first call something like iconv('utf-8','utf-8') to clean up the input data and that doesn't make much sense since htmlspecialchars() essentially does that already. But, in order to help debugging there should be some way to see why an htmlspecialchars() call failed so a last_error() function similar to how it is handled for json decoding would make sense. Previous Comments: ------------------------------------------------------------------------ [2012-07-01 15:12:31] chris at cbsinteractive dot com Happening our production servers, can replicate, PHP 5.3.10, Centos 5.6 ------------------------------------------------------------------------ [2011-09-27 22:43:02] rudd-o at rudd-o dot com Reported to /r/lolphp here: http://www.reddit.com/r/lolphp/comments/kso6p/if_error_reporting_is_on_htmlspecia lchars_will/ Do you guys realize there is an ENTIRE COMMUNITY of people devoted to the collective practice of FACEPALMING at PHP's fails? Hahaha. ------------------------------------------------------------------------ [2011-06-01 18:36:28] larry at garfieldtech dot com 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? ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=47494 -- Edit this bug report at https://bugs.php.net/bug.php?id=47494&edit=1