Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78775
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CC2E198C-1B05-4329-B13D-47787EBE9FFC@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>
Date: Wed, 5 Nov 2014 22:00:01 -0500
Message-ID: <CAL+t6cESCv6s2AHGubuJ+vK26wpq0Uzn39JBLy+vZD8SNskqXw@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=001a11c2400c707fde050727e4cc
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--001a11c2400c707fde050727e4cc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 checking
> 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 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=E2=80=99re suggesting we change the fundamental approach of PHP in te=
rms 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=E2=80=99re sugge=
sting 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 differe=
nt 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.

--001a11c2400c707fde050727e4cc--