I've read some of the earlier discussion (not all, require sleep will read more tomorrow).
To be clear I don't want to start a naming discussion again. If we have a new name for $_POST or not isn't the main focus of this PR. I want to allow PUT, PATCH and DELETE and handle them the same way as POST so we get populated globals with data we could later filter and use. Most of the frameworks work around this limitation in the core so I thought it might be in place to suggest we allow these request methods. On Mon, Sep 14, 2015 at 11:38 PM, Ryan Pallas <derokor...@gmail.com> wrote: > > > On Mon, Sep 14, 2015 at 3:22 PM, Daniel Persson <mailto.wo...@gmail.com> > wrote: > >> Hi. >> >> I've not been a member for too long so I might have missed if this have >> been discussed earlier. >> >> But I've created a small PR to the basic request handling to support PUT, >> PATCH and DELETE. >> >> https://github.com/php/php-src/pull/1519 >> >> Summary: >> >> Added support for request methods with the smallest change possible. >> History: >> >> HTTP 1.0 had only support for GET, POST and HEAD. >> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010 >> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH. >> Pull request explaination: >> >> In this pull request I try to add put, patch and delete with changing as >> few functions as possible. I simply handle the new verbs as POST. As >> defined in HTTP 1.1 they are similar in input data requirements and differ >> only in usage. >> > > +1 from me, would love to see the verbs supported more fully. (though my > approval means quite literally nothing). How does this affect something > like the ini settings for variable order? IE. does GPC change from GET -> > POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb > is available for any single request, this makes the most sense for me. > > >> >> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE >> but >> I think this might be more confusing. Or we could move from $_POST to a >> new >> global not tied to a verb. Example $_PARSED_INPUT > > > As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons > a) the name is 2 words, all other super globals are single words (unless > there's one I do not know of) and b) It feels like too long a name, sure in > an IDE it will auto-complete for us, but for quick edits in vim for > example, this name would suck. But my only problem with it is on a name > level, about about just $_INPUT or does this seem to conflict with > $_REQUEST which holds multiple super globals worth of data already. >
