Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76594
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAPRqa+Hu4dqCs3X7O+Kh3A15eRQG-savV+2i-R=A3VGp-t6fxA@mail.gmail.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>
Date: Sun, 17 Aug 2014 01:10:17 +0100
Message-ID: <CAGAGxbYGfzZh+GTLF1QjfC8Bt27bCoWUiueJZhxHfwiG_zLXtQ@mail.gmail.com>
To: Park Framework <park.framework@gmail.com>
Cc: Chris Wright <cw@daverandom.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Native support - PUT request, multipart form data
From: cw@daverandom.com (Chris Wright)

On 17 August 2014 00:47, Park Framework <park.framework@gmail.com> wrote:
> Variable $_PUT is already a popular name.
> Many for yourself already so it was called, at the bottom link.
> http://stackoverflow.com/search?q=PHP+%24_PUT
>
> But I like the name $_DATA - it is universal for any request method.

IMO $_BODY would make more sense, $_DATA is very ambiguous.

> For frontend developers, this name is very clear:
> $.ajax({
>     type: "PUT",
>     contentType: "application/json",
>     data: {"name": "value"}
> });
>
> Except multipart form data, needed and native support for application/json.
>
> In many languages (Java, Python, ASP), it has long been there.
> It is a pity that the PHP in 2014, it has not yet implemented.

For the record, IMHO what is required here is a *bundled* OO request
abstraction extension, which would expose the underlying parser
routines in such a way that conversions of the input to a data
structure can be done with a single call. but *not* make any
assumptions about what is being done in the application. It has never
sat well with me that multipart inputs cannot be accessed as a raw
string.

I haven't actually given any though to what this API would look like though...