Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78355
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHsEcH_m3MHq2qTa=zrtZs9Ub1SoimeHJ1A9s9Efwdu6U9APJw@mail.gmail.com>
References: <CAKOpQSwS=Xck41sQQyEYGG8L3VHq+fRWjy0dDorbwZaVWMLCow@mail.gmail.com>
	<776669CE-9E8C-4069-9834-C7275CCA0EF4@ajf.me>
	<CAKOpQSwRtSU1LNmftyY1b09SONBCfwS-qiMK4gct6uFiW3CSjw@mail.gmail.com>
	<CAPhkiZwb13FmX+sQLx0Ki52KuwJ4HWTj-84UqcZq3GYPFL8Tnw@mail.gmail.com>
	<E8F7D721-767C-4E6E-B0BB-F0DEFEB308B2@ajf.me>
	<CAF9U7z_0cgwWFEoShU9rJhoOZttztcZk_NAqoXnSuAro-w3kew@mail.gmail.com>
	<8CB055D4-F164-4DF3-B019-684BAE7E016E@ajf.me>
	<543D47C1.9050009@lerdorf.com>
	<etPan.543d4c0e.216231b.12d@Mikes-iMac.local>
	<543D4CE1.5000109@lerdorf.com>
	<543D6864.10508@gmail.com>
	<543D85E6.2020507@lerdorf.com>
	<CAKOpQSyTSZeXppZ-f9OeNfA9=Q58jte1fH6zcuzxYZ+qK7-6JA@mail.gmail.com>
	<57b7a3681d6c2c7ae123c8921b2d19d6@mail.gmail.com>
	<CAHsEcH_m3MHq2qTa=zrtZs9Ub1SoimeHJ1A9s9Efwdu6U9APJw@mail.gmail.com>
Date: Sun, 26 Oct 2014 16:36:14 -0400
Message-ID: <CAA8DMBsmnzbSR-qSvhmjWMVDvR=p_VrZCwVsTcL_ve3+ULxcNg@mail.gmail.com>
To: Dave <catch.dave@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: figureonecpr@gmail.com (Sanford Whiteman)

> The only way to do this in PHP now is write a userland function that parses
> multipart form data, which is non-trivial.

In addition to PECL HTTP, you might try PECL Mailparse, which is also
going to be better-tested than anything written in userland.

I sympathize with your overall point: even without a new superglobal,
it would be cool to be able to reuse the same parser from $_POST.

Still, just to put this out there: receiving multiparts via PUT can be
part of a legit RESTful interface, but that doesn't mean that decoding
multiparts should be automatic. It shouldn't be surprising that it PHP
treats the entity as an opaque block of data by default, since it's
perfectly RESTful for _the MIME-encoded body_ to be the stored
resource.  Imagine an e-mail archive that PUTs to
/user/$username/sent/$messageid.  Decoding the MIME message on
resource create/update would be inappropriate in that case, a huge
waste of resources.  You might lazy-decode the resource only upon GET
/user/$username/sent/$messageid/part/1.  Within the same installation,
you might want to decode other PUTs upon upload, so having a simple
on/off for a new superglobal wouldn't work.

-- S.