Re: HTTP supergloblas and request body/query (was: Parsing PUT data)

hi! On Wed, Oct 2, 2013 at 8:15 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner <mike@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). I totally agree with you here. Unlike the other related changes, the impact on existing code is much larger here, for little gain. I am in favor of not touching them, at all. >> 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. Again, I totally agree. > 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. However I could imagine some new ways to deal with inputs, rest/http/services friendlier. But it is a tricky area, both from an API design and security points of view. Cheers, -- Pierre @pierrejoye | http://www.libgd.org