Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78778
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 66.111.4.25 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAL+t6cESCv6s2AHGubuJ+vK26wpq0Uzn39JBLy+vZD8SNskqXw@mail.gmail.com>
Date: Wed, 5 Nov 2014 22:53:15 -0500
Cc: Andrea Faulds <ajf@ajf.me>,
 Patrick ALLAERT <patrickallaert@php.net>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: willfitch@php.net (Will Fitch)


> On Nov 5, 2014, at 10:00 PM, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
>=20
>=20
> On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch <willfitch@php.net> wrote:
>=20
>=20
>=20
> 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.
>=20
>=20
> 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. =20

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.

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 valuable time.


>=20
> [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
> =20
>=20
> You=E2=80=99re suggesting we change the fundamental approach of PHP in =
terms of what these superglobals represent.
>=20
>=20
> 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.
> =20
> I think from the feedback on this list, the approach you=E2=80=99re =
suggesting is far from welcome. Perhaps this is something you should =
stop arguing and start looking at improving your RFC with something =
that=E2=80=99s different and potentially acceptable.
>=20
>=20
> =20
> Improving the RFC is precisely what I'm looking to do :)
>=20
> 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.
>=20
>=20