Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78515
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
Date: Fri, 31 Oct 2014 16:19:21 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8AA031AF-6A31-4B71-8DCF-A334B384F4EC@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: ajf@ajf.me (Andrea Faulds)


> On 30 Oct 2014, at 18:23, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
> I've started a draft RFC, but please be patient as this is a working =
in
> progress, here https://wiki.php.net/rfc/http-interface on the wiki.
>=20
> The point here is to allow users to implement their own HttpRequest =
and
> HttpResponse classes that can deal directly with the raw =
request/response
> messages in any way the user deems fit. This alleviates cases like =
"what
> about when I want to have $_PUT or $_DELETE" and removes the ambiguity =
of
> the $_POST, $_GET superglobals to a more conforming way of handling =
the
> messages.

OK, I=E2=80=99ve gone and re-read the RFC and I finally understand this =
proposal, sorry for my previous misunderstanding. You=E2=80=99re =
proposing a mechanism to plug in your own parser for the HTTP message =
headers and body, right?

I=E2=80=99m not sure I really see what it solves, though? Why should we =
allow users to implement their own slow parsers in userland? Why can=E2=80=
=99t we just have a single built-in parser like we=E2=80=99ve had the =
last two decades? I don=E2=80=99t see the point.
--
Andrea Faulds
http://ajf.me/