On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch <willfi...@php.net> wrote:
> > > > Easy - you have no idea what the input type is from PUT without checking > the incoming type. With POST, you know exactly what it is. PUT input code > be JSON, multipart mime, a file or a whatever the dev wants. > That's not necessarily true. There are many APIs that will send POST requests with a JSON payload in the request body. This is specifically why PHP won't bother parsing the request entity body unless the content-type header is form ulr-encoded. Additionally you have to take Content-encoding[1] into consideration as HTTP doesn't require that the body of a POST request be url-encoded, just that the client specifies the content-encoding and content-type[2][3] for entity decoding and then it becomes up to the server how to handle or even accept the entity. [1] http://tools.ietf.org/html/rfc2616#section-14.11 [2] http://tools.ietf.org/html/rfc2616#section-14.17 [3] http://tools.ietf.org/html/rfc2616#section-7.2.1 > > You’re suggesting we change the fundamental approach of PHP in terms of > what these superglobals represent. Not at all, $_GET and $_POST in PHP have always represented form data. I wish to keep that intact. This approach merely amends under which HTTP verbs form data can be accepted and the potential to accept media types other than form/url-encoded. If the latter part deviates too much from the concept of form data (it likely does) then that can become a separate vote in the RFC. > I think from the feedback on this list, the approach you’re suggesting is > far from welcome. Perhaps this is something you should stop arguing and > start looking at improving your RFC with something that’s different and > potentially acceptable. > > Improving the RFC is precisely what I'm looking to do :) Surely the only way to find out what is or is not acceptable is to poll others get some form of popular consensus. Perhaps you should take the discussion as less of a battle and more of an opportunity to voice individual objectivity? I have no intention of being hostile. I'm also more than open to the possibility that this RFC may not be favored, but that doesn't negate the effort to build a more favorable RFC based on this discussion.
