Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78779
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9FB8B541-A040-4C0E-8884-A1EA06B3C266@php.net>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com>
	<CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com>
	<1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me>
	<CAL+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@mail.gmail.com>
	<468730E8-4C38-49A3-A61A-59E107313D79@ajf.me>
	<CAL+t6cGPiqZXx2rQCzSV-PCzAAJtMWi6xteCU0GB0XjsB4wSpA@mail.gmail.com>
	<CC2E198C-1B05-4329-B13D-47787EBE9FFC@php.net>
	<CAL+t6cESCv6s2AHGubuJ+vK26wpq0Uzn39JBLy+vZD8SNskqXw@mail.gmail.com>
	<9FB8B541-A040-4C0E-8884-A1EA06B3C266@php.net>
Date: Wed, 5 Nov 2014 23:02:56 -0500
Message-ID: <CAL+t6cGmEonNk0=Dkmih2G96WrXFDrcsn376eN0RjuuWWGPv4g@mail.gmail.com>
To: Will Fitch <willfitch@php.net>
Cc: Andrea Faulds <ajf@ajf.me>, Patrick ALLAERT <patrickallaert@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04138ae374aaff050728c537
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--f46d04138ae374aaff050728c537
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 5, 2014 at 10:53 PM, Will Fitch <willfitch@php.net> wrote:

>
> > On Nov 5, 2014, at 10:00 PM, Sherif Ramadan <theanomaly.is@gmail.com>
> wrote:
> >
> >
> >
> > On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch <willfitch@php.net> wrote:
> >
> >
> >
> > Easy - you have no idea what the input type is from PUT without checkin=
g
> the incoming type.  With POST, you know exactly what it is. PUT input cod=
e
> 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 wh=
y
> 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 reflecte=
d
> in the different meaning of the Request-URI. The URI in a POST request
> identifies the resource that will handle the enclosed entity. That resour=
ce
> 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 yo=
u
> should not assume one is similar to the other - especially based solely o=
n
> 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=E2=80=99re trying to change PHP=E2=80=99s form handling=
 approach with
> your view of what PUT could/should be doing.  Don=E2=80=99t 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=E2=80=99s blowing my mind that you are still arguing this point, and I=
 believe
> it=E2=80=99s 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 valuabl=
e
> 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.

--f46d04138ae374aaff050728c537--