Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69320
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.50 as permitted sender)
References: <CAH8Mpnk6By7E_xn2oXNyvdvKGq=7V-_KOp2Kam-Ltj8Bt4WrHg@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAH8Mpnk6By7E_xn2oXNyvdvKGq=7V-_KOp2Kam-Ltj8Bt4WrHg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-E520E124-61E0-4493-BED6-918527E168AD
Content-Transfer-Encoding: 7bit
Message-ID: <FC462A64-FBAD-4E5F-B023-017DE3C6E8A8@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>,
 Ryan McCue <lists@rotorised.com>, Tjerk Meesters <datibbaw@php.net>
Date: Tue, 24 Sep 2013 08:42:20 -0700
To: Daniel Lowrey <rdlowrey@gmail.com>
Subject: Re: Parsing PUT data
From: catch.dave@gmail.com

--Apple-Mail-E520E124-61E0-4493-BED6-918527E168AD
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Thanks Daniel. My thoughts on your response:

> Where does it stop? This is the problem I see with all the requests to sup=
port for PUT similarly to POST.=20
Right here with PUT. Providing a RESTful interface is hugely common and $_PU=
T is the only one missing to complete REST. PUT is the glaringly obvious one=
 missing.=20

> You could easily write a parser in userland to accomplish the same thing.
I did originally. But it became obvious that (a) it's a common problem; (b) b=
eing non-trivial, it would a require very wide set of test cases to ensure i=
t won't break in some random edge case; and (c) the functionality already ex=
ists for POST.=20

Other languages (Ruby, for example) make REST very easy. Multipart support f=
or PUT was literally the only issue I personally encountered when writing a p=
ublic REST API in PHP.

Dave.

On 24/09/2013, at 7:59, Daniel Lowrey <rdlowrey@gmail.com> wrote:

> > In short, in order to provide a proper REST service that supports multip=
art
> > form data, we need someway to parse data sent via PUT (data is available=

> > via php://input, but it needs to be parsed).
>=20
> Multipart entity parsing is fairly straightforward. You could easily write=
 a parser in userland to accomplish the same thing. Unless you're doing a ve=
ry high volume of CRUD via PUT the performance hit of doing this in userland=
 should be negligible.
>=20
> That said, I think exposing a function to do this could be a useful additi=
on, and since PHP already has code to parse these entities for POST requests=
 it shouldn't be too much work to expose that via something like a new mime_=
multipart_parse() function. It's not really a priority for me, but you can p=
robably find someone to work on this for you if you're not a C person.
>=20
> The bigger issue here is that the superglobals are a leaky abstraction. An=
y HTTP request method is allowed to have an entity body, so should we also c=
reate $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used reques=
t methods? Where does it stop? This is the problem I see with all the reques=
ts to support for PUT similarly to POST. PHP web SAPIs support 95% of the HT=
TP use-cases people have, but the abstractions break down after that and con=
tinuously bolting on support for individual scenarios beyond that would be a=
 mistake IMO.

--Apple-Mail-E520E124-61E0-4493-BED6-918527E168AD--