On Fri, Oct 31, 2014 at 12:19 PM, Andrea Faulds <a...@ajf.me> wrote:
> > > > I’m not sure I really see what it solves, though? Why should we allow > users to implement their own slow parsers in userland? Why can’t we just > have a single built-in parser like we’ve had the last two decades? I don’t > see the point. > > For one, it would solve the problem addressed by the bug report ( http://php.net/55815) listed in the RFC, where users are asking for additional features to parse and handle different kinds of requests like PUT, which PHP currently doesn't do. Additionally, it solves problems such as filtering input from the request with a more abstract interface that doesn't rely on modifying or copying globals. The implementation can be devised to do filtering at the request level or even lazy-loaded so that filters are only applied when the data is requested. In addition, you could utilize this approach to apply different kinds of custom filters based on the request type using the onReceive hook, for example. Further more it can be used to ensure that the request data is immutable so that there is no wonder if the superglobals have been modified/tainted. This is something many frameworks try to abstract themselves in fear that someone might accidentally modify the superglobal variables (as this is very easy to do in userland).
