Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <DC15CB30-2B57-4FEF-A679-D82AE02A78F4@heroku.com>
References: <CAPRqa+G7_quRQ-NR04DChPEZeevuRBHX_1GbOCO+N4VXnzrCTw@mail.gmail.com>
	<CAGAGxbYjc7MAnKQBNB6hb6StsWaRMshxUZieebmoYXHeNmFGyw@mail.gmail.com>
	<CAPRqa+Hu4dqCs3X7O+Kh3A15eRQG-savV+2i-R=A3VGp-t6fxA@mail.gmail.com>
	<20140817021822.9AEBE261C47@dd15934.kasserver.com>
	<DC15CB30-2B57-4FEF-A679-D82AE02A78F4@heroku.com>
Date: Sun, 17 Aug 2014 21:55:54 +0100
Message-ID: <CAGAGxbas-MHC0SVbgNTsYCdr2fQqKaUDax+TiCVDrE-h5wXGXw@mail.gmail.com>
To: David Zuelke <dz@heroku.com>
Cc: Thomas Bley <mails@thomasbley.de>, 
	"internals@lists.php.net" <internals@lists.php.net>, Chris Wright <cw@daverandom.com>, 
	Park Framework <park.framework@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Native support - PUT request, multipart form data
From: cw@daverandom.com (Chris Wright)

On 17 August 2014 11:49, David Zuelke <dz@heroku.com> wrote:
> That does not make any sense; applications could accept XML, CSV or whate=
ver else just as well.
>
> The original proposal is not very useful. $_GET contains parsed query str=
ing info, $_POST contains parsed HTTP request body information if the media=
 type is application/x-www-urlencoded or multipart/form-data. Deserializing=
 that makes sense as the rules for it are in the HTTP spec.

(warning: nitpicking) actually, neither of these types are part of the
HTTP specification, the protocol specification doesn't deal with how
to handle content, only how to transmit it. RFC 2616 makes no mention
of it, and RFCs 7230-7235 don't either.

> $_PUT/$_BODY/$_DATA would then have to contain the raw body contents, at =
least if the media type isn't one of the above, for consistency. That'd sav=
es the file_get_contents() call, and given how a request handler uses at mo=
st once, I'm not sure such a change is worth it.

I completely agree that there should be no special processing in the
case of any content-type that is not already handled by $_POST, but I
don't see the harm in handling those content types for arbitrary
methods.

Personally my ideal option would be to deprecate $_POST and $_GET in
favour of $_BODY and $_QUERY, respectively, which would be populated
the same way regardless of the request method (not just PUT and POST).
Similarly $_FILES would be populated for any multipart/form-data
request entity, regardless of request method.

No other content type could be reasonably handled since there is
ambiguity in how it would be handled (to take the alternate examples
David mentioned, json_decode() has options and there are a million and
one ways to handle XML). One might suggest having these configurable
with ini options or runtime functions, but both of these would largely
defeat the purpose of such automatic handling.

I agree with Julien that this is not the sort of thing that should go
into a point release, and if $_POST/$_GET were to be deprecated then
this would be a change for 7, probably with removal not before 8.

All that said, I personally don't find the requirement for writing 2
additional lines to parse the data such a huge burden. I'm not against
it, but neither will I be particularly upset if it doesn't happen.