On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <m...@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
