Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81321
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54C8D36E.7010803@php.net>
References: <54C8D36E.7010803@php.net>
Date: Wed, 28 Jan 2015 19:08:44 +0100
Message-ID: <CAF+90c98Mrj17p7ZPc=0eAYyt01-8rCpSBX9wRrKPKFO+gdZTg@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c7dd21f493d050dba43bc
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d043c7dd21f493d050dba43bc
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:

> Hi,
>
> Discussion has been very low on this topic since it was proposed on
> August 19th, so I just opened the vote on the RFC whether to add
> pecl_http to the core. The vote will be open until about 12:00 UTC on
> Friday, February 6th.
>
> https://wiki.php.net/rfc/pecl_http#vote
>

I don't feel like this RFC leaves me in a position to make a qualified
choice as to whether this extension should be included or not. There's just
way too little information in here, and I don't think an extension like
this should be added lightly.

I understand that it may not be feasible to include full API design
documents in an RFC, but there's a lot of other things that just aren't
clear to me. A few random points:

 * While the RFC does not mention it, I understand that pecl_http has hard
dependencies on two other extensions. What do these extensions do and how
is the integration in core supposed to be handled?
 * The RFC mentioned that "pecl_http adds processing for json request
bodies into $_POST". Could you elaborate on this, in particular when this
is enabled and how automatic it is? Did you give proper consideration to
the security implications that this has? E.g. are you confident that the
implementation is HashDOS resistant?
 * A number of libraries and frameworks already provide functionality that
intersects with parts of the pecl_http extension. There's also the upcoming
PSR-7 standard that might be of relevance. How does the API exposed by
pecl_http compare to these / follow existing APIs / standards?
 * How does this extension relate to curl, in particular how is the
dependency situation and what happens when the dependency is not met? What
other optional dependencies are there?
 * Why do we need to include these kinds of APIs directly into PHP instead
of the current situations where object oriented HTTP APIs are implemented
by libraries / frameworks and can evolve independently of PHP?

Generally I am not entirely convinced that we should be including any
"high-level" APIs in this direction. With the advent of Composer it is
trivial to include an HTTP library written in PHP. I'm generally not a fan
of including functionality in core if there is no strong reason why it
can't or shouldn't be implemented as a userland library. Including
something in core usually freezes it for all time and makes future
improvements very hard.

What I would be primarily interested in here is the addition of "low-level"
APIs for handling HTTP - in particular functions for parsing raw strings.
This is a performance sensitive part that can benefit from a C based
implementation. (While high-level APIs benefit less from C - or even
anti-benefit by being buggier and harder to adjust.)

TL;DR I need more info to make an informed choice.

Nikita

--f46d043c7dd21f493d050dba43bc--