On 09/18/2012 02:21 PM, Stas Malyshev wrote: > Hi! > >> Filter has already gone down this road--I doubt the value added by having a >> second, much >> more verbose way to call htmlspecialchars()--but I don't see why we must >> continue down >> that path. > > So, you don't think there should be second, more verbose way to call > htmlspecialchars - that's why we should add third, more verbose way to > call htmlspecialchars? Somehow this does not sound convincing to me.
And note that there is actually a good reason. By having htmlspecialchars as a filter you can use it as a default input filter. A strict default filter acts as a safety net against typical XSS flaws. If a developer forgets to apply the correct filter/encoding/escaping (whatever you want to call it) mechanism, then the default filter makes sure the most common cases are covered. Some people make the mistake of associating default filtering like this with always storing escaped data in the backend which simply isn't the case. It is nothing more than a safety net and a way to make it easier to audit data filtering by forcing developers to specify the escaping, if any, they want on every piece of input data. If we want to add more filters for more specific purposes, I am not completely against it, although the more specific they get the more churn there will be. We are not going to be able to kick out weekly releases to address every new nuance of these very specific filters. But they should be implemented as filters compatible with the filter extension so people can use them within that existing context. That doesn't preclude a more approachable function alias from also calling them, of course, much like the htmlspecialchars case. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
