Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69321
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <FC462A64-FBAD-4E5F-B023-017DE3C6E8A8@gmail.com>
References: <CAH8Mpnk6By7E_xn2oXNyvdvKGq=7V-_KOp2Kam-Ltj8Bt4WrHg@mail.gmail.com>
	<FC462A64-FBAD-4E5F-B023-017DE3C6E8A8@gmail.com>
Date: Tue, 24 Sep 2013 12:12:10 -0400
Message-ID: <CAH8MpnmicKY-frZTx1E0R17dhnbQsafF+929W13m5Enp0EKGHw@mail.gmail.com>
To: catch.dave@gmail.com
Cc: "internals@lists.php.net" <internals@lists.php.net>, Ryan McCue <lists@rotorised.com>, 
	Tjerk Meesters <datibbaw@php.net>
Content-Type: multipart/alternative; boundary=047d7b603dcc2e310104e72366b3
Subject: Re: Parsing PUT data
From: rdlowrey@gmail.com (Daniel Lowrey)

--047d7b603dcc2e310104e72366b3
Content-Type: text/plain; charset=ISO-8859-1

Let me be clear: I'm not suggesting we should ignore useful functionality
because of poor design decisions made in the past but I am saying that we
should avoid compounding those mistakes by building on top of them. Would a
$_PUT superglobal be helpful? Sure. But is it a good solution to underlying
problem? Not really.

> it's a common problem;

I can agree with this -- PUT's use is widespread and adding support is
probably sensible. That said, your other arguments don't hold much water:

> I did originally.

An inability on your part to write working code doesn't equate to "PHP
should implement this for me"

> it would a require very wide set of test cases to ensure it won't break
in some random edge case

The need for testing doesn't diminish if the parsing is implemented in C
vs. PHP

> Multipart support for PUT was literally the only issue I personally
encountered when writing a public REST API in PHP.

Are you sure you didn't need it for your RESTful PATCH requests too:

http://tools.ietf.org/html/rfc5789

And what happened when you implemented Expect: 100-continue headers in your
RESTful requests?

Basically, if you're suggesting that adding $_PUT would solve all of PHP's
problems with full HTTP protocol support then I can't agree.



On Tue, Sep 24, 2013 at 11:42 AM, <catch.dave@gmail.com> wrote:

> Thanks Daniel. My thoughts on your response:
>
> Where does it stop? This is the problem I see with all the requests to
> support for PUT similarly to POST.
>
> Right here with PUT. Providing a RESTful interface is *hugely* common and
> $_PUT is the only one missing to complete REST. PUT is the glaringly
> obvious one missing.
>
> 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) being non-trivial, it would a require very wide set of test cases to
> ensure it won't break in some random edge case; and (c) the functionality
> already exists for POST.
>
> Other languages (Ruby, for example) make REST very easy. Multipart support
> for PUT was literally the only issue I personally encountered when writing
> a public 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
> 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.
>
>

--047d7b603dcc2e310104e72366b3--