Hi Rasmus, On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > 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.
I feel it needs to be reiterated that the escaper rules are very predictable and very seldom change as the regular expressions in the Zend\Escaper class demonstrate. Each is bound to official standards for Javascript, CSS and HTML respectively and most of the rules, defined using the OWASP's recommendations as implemented in ESAPI, are really clearcut - escape everything except alphanumerics and a small range of "safe" characters (CSS even has NO safe chars outside alphanumerics). HTML and URL encoding are the only permissive variants and these are already well known in PHP. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
