Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69318
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.173 as permitted sender)
MIME-Version: 1.0
Date: Tue, 24 Sep 2013 10:59:19 -0400
Message-ID: <CAH8Mpnk6By7E_xn2oXNyvdvKGq=7V-_KOp2Kam-Ltj8Bt4WrHg@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>, Ryan McCue <lists@rotorised.com>, 
	Tjerk Meesters <datibbaw@php.net>, catch.dave@gmail.com
Content-Type: multipart/alternative; boundary=001a11c275da9b368604e72261ca
Subject: Re: Parsing PUT data
From: rdlowrey@gmail.com (Daniel Lowrey)

--001a11c275da9b368604e72261ca
Content-Type: text/plain; charset=ISO-8859-1

> 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).

Multipart entity parsing is fairly straightforward. You could easily write
a parser in userland to accomplish the same thing. Unless you're doing a
very high volume of CRUD via PUT the performance hit of doing this in
userland should be negligible.

That said, I think exposing a function to do this could be a useful
addition, 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 probably find someone to work on this for you if you're not a C
person.

The bigger issue here is that the superglobals are a leaky abstraction. Any
HTTP request method is allowed to have an entity body, so should we also
create $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used
request methods? Where does it stop? This is the problem I see with all the
requests to support for PUT similarly to POST. PHP web SAPIs support 95% of
the HTTP use-cases people have, but the abstractions break down after that
and continuously bolting on support for individual scenarios beyond that
would be a mistake IMO.

--001a11c275da9b368604e72261ca--