Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78852
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender)
Message-ID: <545D3E66.6060202@sugarcrm.com>
Date: Fri, 07 Nov 2014 13:49:26 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Sherif Ramadan <theanomaly.is@gmail.com>
CC: Andrea Faulds <ajf@ajf.me>, Patrick ALLAERT <patrickallaert@php.net>, 
 PHP Internals <internals@lists.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>	<545C1823.8050404@sugarcrm.com> <CAL+t6cG+j7emBboNcnZi5wC6QtjFtmEcDGgsnA6sJVx9qpD41A@mail.gmail.com>
In-Reply-To: <CAL+t6cG+j7emBboNcnZi5wC6QtjFtmEcDGgsnA6sJVx9qpD41A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> makes user land code more readily equipped to enable the user to do that
> handling. In the same way that it does for POST. This creates some more

Well, for POST PHP actually parses the data - url encoding, form
encoding, files, etc. - and puts it into the data structure. For generic
REST case, it'd be harder to do the same because there are too many
options of how the data could arrive.

> For this to be possible in a more generic sense this would mean that PHP
> only relies on the Content-encoding and Content-type headers to
> determine how to decode the payload and parse its contents into super
> global variables such as $_POST and $_FILES. This is currently what
> PHP's SAPI implementation already does. The changes required to make

Currently, it supports only basic form encodings. But if we get into
handling all application types, it's a huge can of worms to have in core.

> If the Content-type is applicatoin/json, for example, instead of the
> normal application/x-www-form-urlencoded, PHP would simply parse the
> enclosed entity body as JSON rather than urldecode it. If the

That's not as easy as you think. Even JSON can have different encodings,
be parsed in different way (json_decode right now has three options, and
could have more in the future) an so on. But that's only JSON - why
would then we single out JSON and not support XML or YAML or iCalendar
or any other 1001 formats?

> multipart/form-data MIME in the same way that post does, so encoding
> can't vary. If the Content-type header is application/binary, for
> example, we can simply make the file available in $_FILES or just leave

There's no application/binary in standard MIME, ITYM
application/octet-stream, but files do not have to be octet-stream, they
can be of any type. And when you get the data, you in general don't know
if it is meant to be a file or field or something else - that's on the
app to decide. In the specific multipart/form-data case, we have
content-disposition which tells us it was a file upload, but if it's not
that format, all bets are off. In fact, nothing prevents a client from
sending a file contents but the server treating it as a regular data field.

> Here, I'm just proposing that PHP take on the addition of PUT handling
> in a similar fashion that it does for POST, but only in the even that

The problem is that while POST is used for forms (not only, but
frequenly especially in webform context), PUT can be used for anything.
We could of course make the core to identify PUT with
mulitpart/form-data and parse it in the POST manner, I don't see any
technical reason preventing that, but I think if you're already doing
generic REST, then you'd be better served by generic parsing library (or
a set of them) than by selecting one use case. I could be wrong of
course, if PUT+mulitpart/form-data is a frequent use case and I just am
not aware of it, then it makes sense to make RFC to add handling of it.
So the question here is how common is the case of PUT+mulitpart/form-data?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/