Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78488
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <36B5E957-01C0-40F2-B4CE-5B02D11ACA14@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<CABRjmp9p=+zGiqn_nuVJcDAK0po98FnDhb7wTmG66tob4u0GOw@mail.gmail.com>
	<CAL+t6cFh77D0FufKGy_OeLO7O0=ky46Zv8S=oTLFP8VnZRtCvw@mail.gmail.com>
	<36B5E957-01C0-40F2-B4CE-5B02D11ACA14@ajf.me>
Date: Thu, 30 Oct 2014 16:33:08 -0400
Message-ID: <CAL+t6cGERpWQDSmqfHVYgb4hzKOtFaKWPKt2Lvm44FNyoE-ebg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Florian Margaine <florian@margaine.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2400cd5624f0506a9c964
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--001a11c2400cd5624f0506a9c964
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 30, 2014 at 4:24 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> > On 30 Oct 2014, at 19:49, Sherif Ramadan <theanomaly.is@gmail.com>
> wrote:
> >
> > Well, let's look at how well providing implementation has worked out for
> > PHP so far.
> >
> > GPC variables are implementation. They pose rigidity to userland code
> for a
> > number of reasons. For example, if you do send a PUT request to PHP, PHP
> > will not bother populating GPC at all. Instead it leaves the user to
> define
> > their own handling from the input stream directly. If you do send
> GET/POST
> > requests to PHP, the variable names can be mangled and $_GET/$_POST are
> > treated differently for encoding as one is run through url_decode and the
> > other is not.
>
> We could just fix these problems rather than adding an entirely new
> implementation.
>


Yes, this proposal is intended to do two things. 1) Fix the aforementioned
problems. 2) Improve upon the capabilities of PHP's request handling for
future use cases through a unified interface.

To say that this proposal and fixing the aforementioned problems are two
distinct options (as in we can either fix these problems or go with this
proposal) is a very reductive form of thinking in which the only outcome
favors one party or the other.

My proposal is intended to result in a win-win situation where everyone
involved can be satisfied, not an ultimatum.

If you consider all of the major existing PHP frameworks today there is
always some form of HttpRequest class handling these things and almost all
of them do it slightly differently. What's worse, is they are all very
inefficient implementations that I believe can be done far more efficiently
in php-src. A lost of them are also unnecessarily complex. I think all of
this can be simplified if the interface is just laid out in a
straight-forward manner and then userland implementations will find less
and less reason to over-engineer the implementation.


> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

--001a11c2400cd5624f0506a9c964--