> On Nov 5, 2014, at 10:00 PM, Sherif Ramadan <theanomaly...@gmail.com> wrote: > > > > 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.
I think a simple quote from RFC 2616 is necessary: "The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request." (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) There is nothing relevant to data transformation between PUT and POST. It is, for all intents and purposes, two completely different methods and you should not assume one is similar to the other - especially based solely on what you want PUT to do. PUT can contain query strings, POST-like bodies and files or a combination of any. Bottom line - you’re trying to change PHP’s form handling approach with your view of what PUT could/should be doing. Don’t do that. It’s blowing my mind that you are still arguing this point, and I believe it’s time to put it to bed. Come up with a better solution, put this RFC to a vote (even without a patch) or retract it. You have have almost nothing but criticism, and this thread is at the point of wasting valuable time. > > [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. > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
