Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81323
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.181 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54C92DE9.8010200@php.net>
Date: Wed, 28 Jan 2015 19:43:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <54C8D36E.7010803@php.net> <CAF+90c98Mrj17p7ZPc=0eAYyt01-8rCpSBX9wRrKPKFO+gdZTg@mail.gmail.com>
In-Reply-To: <CAF+90c98Mrj17p7ZPc=0eAYyt01-8rCpSBX9wRrKPKFO+gdZTg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: mike@php.net (Michael Wallner)

On 28/01/15 19:08, Nikita Popov wrote:
> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net
> <mailto: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?

As stated in one of the discussion threads, those dependencies could be
merged to main/ and/or ext/standard. In the current patch the persistent
handle API is in main and the property proxy API is in ext/standard.

The resource factory and persistent handle API provides a similar but
extended set of functionality of what zend_list provides.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-raphf/php__raphf_8h.html

The property proxy handles R/W access to object properties that
represent C struct members. Similar functionality was supposed to be in
ZE2, but disfunctional to my findings.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-propro/php__propro_8h.html

>  * 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?

Not necessarily. It suffers from the same issues, if any, like
php_json_decode().

>  * 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?

The first release of pecl_http was exactly ten years ago and it has
evolved a lot, of course. So I'm not sure what it should have followed.

>  * How does this extension relate to curl, in particular how is the
> dependency situation and what happens when the dependency is not met?

libcurl is the only client provider currently, so if libcurl is not
available at build time, the client functionality is unavailable at
runtime (i.e. http\Client is not instantiatable).

> What other optional dependencies are there?

Optional build time dependecies are json, iconv and hash.
All of them not of major importance.

json: decoding application/json entities
iconv: translating query strings
hash: generating ETags for dynamic entities

>  * 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?

We don't need to. Including it in core was a topic every other year, but
I never felt it was ready before.

> 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.

I really had a problem to imagine what people would have liked to read
in the RFC; all I could think of had a touch of cheesy commercials, so I
refrained from it and waited for a discussion to spoil, which obviously
never happened.


-- 
Regards,
Mike