On 2 October 2013 17:15, Nikita Popov <nikita....@gmail.com> wrote: > On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner <m...@php.net> wrote: >> >> Since ever people are confused by _GET and _POST superglobals, >> because, despite their name, they do not (really) depend on the >> request method. Therefor I propose to phase out $_GET and name it >> $_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not >> 100% confident with the latter yet, though). > > > I don't think this kind of change is worth it if you just rename two very > heavily used variables. If something in this direction is changed the change > should be more thorough (including getting away from superglobals and > representing the request state by an immutable object).
Well, what I want and what is in core may diverge. May I suggest you take a look at pecl_http-v2, I'd greatly appreciate any feedback. > >> >> There are already parsers for application/x-www-form-urlencoded and >> multipart/form-data in the core. One could think of providing an API >> to add content type handlers from extensions, ext/json may be an >> example, like it is hacked into pecl_http-v2. > > > I would *strongly* recommend against adding additional body parsers that are > automatically invoked based on the content type. Adding additional parsers > creates a high security risk. E.g. exposing ext/json as it is now would open > you to a denial of service attack (if I'm not mistaken). There has been a > long history of security vulnerabilities (both DOS and RCE) related to > unnecessary or incorrect exposure of request body parsers. A prominent > recent example are the RCE vulnerabilities in Rails caused by the exposure > of YAML and JSON parsers. Pointers, references, evidences? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
