Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78543
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <5453D6D5.2070705@garfieldtech.com>
Date: Sat, 1 Nov 2014 12:40:55 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <CC36778A-6962-4CCF-8B64-EA5A37370A5A@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <5452B87B.5040009@garfieldtech.com> <CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com> <0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me> <CAL+t6cGanxv3dJONcECupw6Cfzup4s6At6tEcK_=Qagn67RNjw@mail.gmail.com> <5453B114.6050400@gmail.com> <CAL+t6cFCToJJGiCb8JhNe9oQws5UuBdKw+ot3rjUBQQr=7=Bxw@mail.gmail.com> <5453C250.8090803@gmail.com> <CAL+t6cEH7PPMu2G=e4NQau-iOznkG31-d187EMCDY0LFeew68g@mail.gmail.com> <CABRjmp-b1jGD1SBTxmnJFLKi++WbL4TBggijN+VfSjRjPMJYPQ@mail.gmail.com> <CAL+t6cF7t7shs78xSiBfGxZSCqh5zcU-B_WWjK5J9ebiB=PTQA@mail.gmail.com> <5453D6D5.2070705@garfieldtech.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: ajf@ajf.me (Andrea Faulds)


> On 31 Oct 2014, at 18:37, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> I think the root problem is that you're solving an issue that doesn't =
exist.
>=20
> You're talking about providing alternate ways to parse the raw HTTP =
stream into user-accessible variables, ie, by pushing them into an =
object of a known interface rather than/in addition to the superglobals.
>=20
> In my 15 years of writing PHP I have never wanted to change the way =
the raw HTTP is parsed.  I have, however, frequently wanted to have the =
data accessible in a more logical, semantic, and HTTP-correct way.  =
($_GET is not about HTTP GET, it's about URI query parameters. $_POST =
isn't about HTTP POST, it's about application/x-www-form-encoded.  Etc.) =
 And I've wanted that information available in a non-global, =
OOP-injectable way. But I've never once had any desire to change the way =
an application/x-www-form-encoded is parsed.
>=20
> Implementation problems aside, your proposal is not solving an extant =
problem.
>=20
> If we want to improve PHP's HTTP handling, then having an object that =
exposes the HTTP request in a more logical fashion would be far more =
useful, and/or providing that data in a more logical way so that someone =
in user-space can provide that data in a logical fashion (eg, via a =
PSR-7-implementing object.)  I already stated in an earlier email what I =
felt would be most beneficial for internals to do toward that goal =
(specifically, clean up the streams API so that we can use it directly =
from an OOP world rather than a 1980s C world.)
>=20
> IF internals wanted to add implementation, not just improving streams, =
something like the following would be much more useful:
>=20
> $request =3D http_get_request(PHP_STDIN); // or something
>=20
> Where $request is an object that implements the PSR-7 RequestInterface =
(or at least the read-only parts of it), or something similar.  Then =
implementers can compose that object however they want.
>=20
> Although at least for the near term I think it's better to not do that =
and just do the lower-level plumbing to make FIG's work with PSR-7 =
easier.

This sums up my thoughts on this very well. Nobody needs to change how =
we parse the data. We just need better access to the results of the =
parsing.
--
Andrea Faulds
http://ajf.me/