Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.174 as permitted sender)
MIME-Version: 1.0
Date: Mon, 23 Sep 2013 22:19:51 -0700
Message-ID: <CAHsEcH9WOXf2E7C0=GZqmLLMck2h-nzEgQzO0mCbT3m80AW9+g@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8f502fea7ea5a104e71a4a11
Subject: Parsing PUT data
From: catch.dave@gmail.com (Dave)

--e89a8f502fea7ea5a104e71a4a11
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

Firstly, let me know if this is particularly spammy/inappropriate for this
list.

I just wanted to get some feedback on a long-time feature request (2011)
about treating PUT the same as POST in terms of re-using the existing form
parser. See https://bugs.php.net/bug.php?id=55815 for details.

Normally, I wouldn't have posted this to internals, but as you can see,
there's been no movement on this for a long time.

In short, in order to provide a proper REST service that supports multipart
form data, we need someway to parse data sent via PUT (data is available
via php://input, but it needs to be parsed).
Could be as simple as adding $_PUT / $_FILES for PUT data.


What's the best way to move this forward?
Do I need to create a patch/RFC? Or is this something someone can just pick
up?


Thanks,
Dave

--e89a8f502fea7ea5a104e71a4a11--