Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78763
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com>
	<CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com>
	<1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me>
Date: Wed, 5 Nov 2014 20:29:47 -0500
Message-ID: <CAL+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Patrick ALLAERT <patrickallaert@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bfd0292bf73d4050726a1ff
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--047d7bfd0292bf73d4050726a1ff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 5, 2014 at 7:31 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> > On 5 Nov 2014, at 22:29, Sherif Ramadan <theanomaly.is@gmail.com> wrote=
:
> >
> > From all the people I've spoken with that have a problem with handling
> PUT
> > requests in PHP, it seems that they'd rather have PHP populate
> > $_FILES/$_POST automatically in this case. Which would be relatively ea=
sy
> > to do by modifying the default post reader function in the SAPI
> > http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however,
> that
> > is itself a small BC break.
> >
> > Does anyone have any recommendations on what they think the best approa=
ch
> > is? I'd appreciate any feedback/suggestions/constructive-criticism.
> Thanks!
>
> I don=E2=80=99t think auto-populating for PUT/DELETE etc. is a good idea,=
 they=E2=80=99re
> quite different semantically. If I send a DELETE request to code expectin=
g
> a POST, and PHP pretends it=E2=80=99s a POST request, that=E2=80=99s bad.
>

So you're actually describing two semi-different problems here. One is that
PHP doesn't actually inform you of the HTTP request VERB strictly through
the naming of the super global variables $_POST and $_GET. However, $_POST
being populated, right now, in PHP, strictly means the request verb was
POST and that the content-type header received was multipart form data.
Which means that sending something like a JSON payload (Content-type
application/x-json or whatever) in the body of a POST request still doesn't
populate the $_POST super global variable even though the HTTP request VERB
was indeed POST.

The other problem is that the semantics of REST itself are quite different
from how PHP currently deals with the request data. In that PHP only cares
about form data. However, this is quite antiquated with todays' modern use
of HTTP growing in API-specific functionality. For example, companies like
Twitter and Tumblr, demonstrate a vast majority of their traffic currently
coming in at the API-level where things are usually handled in a RESTful
manner. So for the PHP power houses today, PHP doesn't quite lend itself
well to dealing with these problems first-hand. Instead we have to hack our
way around them in userland, which can be more error-prone and less obvious=
.


>
> However, I think the solution is simple: Add a function to do
> multipart/form-data parsing. Not a suite of functions, not a class, just
> one simple function. That way, for the few people that need it, they can =
do
> $_POST =3D multipart_form_data_parse(file_get_contents(=E2=80=98php://inp=
ut')); and
> their problem=E2=80=99s solved.


> If we can=E2=80=99t expose the parser, we could also just add a function =
to force
> population (force_parse_post_data() or something?). Again, this allows th=
e
> few that need this to do so explicitly, but doesn=E2=80=99t make $_POST a=
llow it
> for everyone else.
>



While that solution solves one specific problem (dealing with multipart
form data of request types other than POST), it doesn't quite tackle some
of the broader issues of dealing with incoming HTTP request in PHP that I
would like to tackle. I also think you're diminishing scope of this problem
and the number of people affected by it. You not only have to think of the
number of programmers dealing with the code, but the number of end-users
indirectly affected by the problem as well. PHP is primarily a web-oriented
language, and I think as such it should deal with these kinds of issues
more readily. If you take a good look at the number of web-based APIs out
there and how certain PHP client libraries try to deal with these kinds of
problems the solutions are sometimes very poorly implemented or just
outright wrong.

We solved password hashing dilemmas with password_hash for a similar reason
in PHP. In that people were just doing it wrong and didn't know any better.
So I think making a more robust, and simpler interface to deal with these
kinds of issues will encourage people to get it right in the future.


> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

--047d7bfd0292bf73d4050726a1ff--