Re: [RFC] [VOTE] pecl_http

From: Date: Wed, 28 Jan 2015 20:38:23 +0000
Subject: Re: [RFC] [VOTE] pecl_http
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-81336@lists.php.net to get a copy of this message
Hi Stas, > On 28 Jan 2015, at 20:30, Stanislav Malyshev <smalyshev@gmail.com> wrote: > > Hi! > >> Personally, I’ve never liked that PHP requires cURL for doing HTTP >> requests. It’s a language made for the web, it should have built-in > > I see no problem in depending on cURL. NIH'ing every part of the > software universe in unfeasible, and if somebody does this one job and > does it well - why not use it? We don't have enough resources here to > implement every detail of the huge protocol like HTTP, and that's the > whole point of opensource to reuse and combine projects. I suppose cURL isn’t so bad… really, the API is the biggest issue with that. HTTP requests in PHP feel like a second-class citizen and must be done through an awkward set of PHP bindings to a C library. That’s awful for a language made for the web. I’d be okay with cURL were it not for the API, I guess. Actually, if we’re to keep HTTP stream wrappers and keep using cURL, then the HTTP stream wrapper should probably also use cURL, right? >> HTTP, and it should share code between its server-side HTTP and >> client-side HTTP stuff. I don’t think that the HTTP stream wrappers >> are a “hack” - they’re what PHP should have had all along. I think we > > HTTP stream wrappers work for some cases, but not for all and for cases > where you need deep involvement with details of HTTP - like headers, > byteranges, content encodings, etc. - they might not be the best API to > deal with it. This is true. The main thing I like about HTTP stream wrappers is that they’re part of core PHP rather than some external library. Also, they support headers, have done for ages. Thanks. -- Andrea Faulds http://ajf.me/

« previous php.internals (#81336) next »