On Wed, Nov 5, 2014 at 10:53 PM, Will Fitch <willfi...@php.net> wrote:
> > > 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. > Correct, the HTTP request verb is about describing the intent of the request, which is what I said earlier. It is not about how to treat the enclosed entity body. For that the specification describes additional headers such as that of Content-type header. Nowhere did I suggest that the request verbs themselves (i.e. PUT and POST) have the same intent. Just that the handling of multipart-form data is not specific to either one of those verbs. > > 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. > I'm trying to take advantage of the fact that PHP can parse the multipart data regardless of the request verb. This is a good thing. It has added benefits. I see no reason why this would be a negative impact on PHP. If anything it makes PHP more useful in dealing with additional request types without the user having to parse the input stream themselves. > > 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. > > I'm sorry you feel that there is a waste of valuable time in this thread. By all means, if you feel that this thread is a waste of your time please disregard it. I have no intention of putting anything to a vote until I feel it is ready. Since it is currently a draft I feel no obligation to retract it. I do appreciate your time and input, however.
