> > The problem with a warning here is that there is usually no way to > prevent it short of using @ or preceding all calls to htmlspecialchars() > with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a > web app and look for that warning to get a really good idea about the > server software being used. And yes, I know people should have > display_errors off in production, but this case is slightly different > because it is so universal. Other user-triggerable warnings are very > code-dependent and there is no universal trigger string you can send to > all PHP apps. Almost all PHP apps call htmlspecialchars() on user input > at some point. > > The call here was whether to throw a warning at all and the idea was > that it was ok to do so as long as it didn't leak to the world for > improperly configured servers that had display_errors on. I would be > fine with removing the warning altogether since sanitizing the string is > an inherent characteristic of the function now and throwing warnings > about the normal operation of a function doesn't make much sense. > > -Rasmus
So in other words this patch I submitted should be fine? https://github.com/php/php-src/pull/111 This particular patch doesn't raise any controversy since it doesn't touch any of that other stuff and simply puts the defined behavior back in place as it should have been. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
