Hi Lars, On Thu, Sep 1, 2016 at 8:59 PM, Lars Strojny <l...@strojny.net> wrote: >> On 31 Aug 2016, at 21:45, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > [...] >> Thank you for voting! >> The RFC is declined 1 vs 13 >> A bit surprised this result. >> >> I requested the reason of objection, but many of them does not disclose why. > [...] >> lstrojny (lstrojny) > [...] > > sorry for not chiming in earlier, but I indeed owe you an explanation. I > believe making ext/filter a part of PHP created more trouble than it solved, > even though I applaud it’s intention. Of course, filtering and validation are > necessary essentials of any secure web application. I nevertheless strongly > believe validation and filtering must live in userland. > Validation and filtering are often very much tied to the domain problem a > user of PHP is to solving and the change rate of the application will be > higher than the change rate of the language (hopefully). To give a more > concrete example: let’s say our problem is we want to validate if a string is > a valid domain because our business is registering domains. Nowadays, top > level domains are introduced quite often and there is no way PHP could have a > nice, up to date whitelist of TLDs all of the time and as a domain > registration business it’s impossible for me to wait for the updated > whitelist in PHP NEXT. That’s why I believe this is something that belongs to > userland so the library that offers (domain) validation can follow a > lifecycle that fits the problem it is trying to solve.
Thank you for reply. It seems many of us is mixed up what "input handling should do" and "business logic should do". There are number of ways how to implement input data validations and input error checks, from ideal to poor, or even bad. The validator is trying "to validate input string (format, used char, length, existence, etc) is expected". Business logic should handle input errors, logical consistency, etc. i.e. Domain whitelisting should be handled by logic generally speaking. I don't understand why new validator would cause more problems than solving. If users validate all inputs (e.g. request headers, cookies, all of post/get tampering), apps became much more secure. This task does not belong to business(app) logic. Even when users use the validator non optimal way, it will improve security. Anyway, bottom line is "There are too many apps that do not validate inputs properly", "Many users do not distinguish 'input validation' and 'logic/mistake check'". It seems. Regards, P.S. I was about to reactivate DbC proposal. This kind of validation is mandatory for DbC. Otherwise, DbC will cause more problems than solving. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
