# [RFC] [DISCUSSION] pecl_http - Thread: https://externals.io/message/81403 - Original archive: https://news-web.php.net/php.internals/81403 - Started by Daniel Lowrey on 2015-01-30T06:28:11+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #81403 — Daniel Lowrey — 2015-01-30T06:28:11+00:00 URL: https://externals.io/message/81403#81403 > I’ve rewritten the RFC for pecl_http and hopefully addressed most of the > things mentioned previously. > > I you still find anything lacking, please let me know, so I can expand the > RFC accordingly. > > And of course, everything else is up for discussion. > Hi Mike :) I'd like to chime in on the discussion ... 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. This, to me, means things like parsing functionality that is conspicuously absent in a web-first language like PHP. HTTP messages, cookies, header parameters, multipart/form-data ... these are all standard HTTP elements for which we have no compiled parsing capabilities in the standard distribution. Adding this functionality in ext/http would be an instant win for my own work and I'm sure for many others as well. Moreover, parsing is the type of functionality that *really* benefits from being compiled as compared to happening in userland. Finally, this type of functionality is pretty vanilla and straightforward -- there is little room for stylistic disagreements in APIs and implementations. No one is going to complain that a multipart/form-data parser API is "zomg so bad I need to tweet my frustration about #php right now." If it parses data how it's supposed to it's generally good enough. These are the kinds of things that ought to be bundled with the standard PHP distribution. They'd be a win for everyone and shouldn't realistically upset or confuse anyone. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. I'm talking specifically here about the Encoding\Stream things. In fact, I had planned to PR essentially the same thing for ext/zlib between now and the 7 feature freeze. This is functionality that isn't specific to HTTP and belongs in ext/zlib, especially considering it relies on the zlib dependencies in the first place. I don't think it's a good idea to do this. It's missing functionality in another extension -- it should be PR'd and included there. PHP is well-known for its perceived "lack of direction" and this kind of overlap is exactly what people point to when they denigrate the language. If we already have these extensions lets update them instead of adding more extensions to cover holes in the existing ones. I'd personally prefer to see new development/inclusions take the wide view of the distribution as one whole PHP and not an incoherent mish-mash of overlapping extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ There are a lot of "extras" here. PHP's existing HTTP functionality is already spread all over the map and bundling this additional functionality certainly won't help to mitigate that. This ties in somewhat with my previous point, but ... we have superglobals, ext/curl, `file_get_contents()`, etc. Do we really need to bundle another extension that depends on curl to make HTTP requests? Do we really need to bring in two other pecl libs as hard dependencies for this? I don't really see enough benefit here to muddy the waters in such a way. Beyond this, http requests are IO-bound transactions ... this is something that can be done quite well (and is already) with existing userland libraries without incurring significant performance degradation. I don't see the need for all this extra stuff to add functionality that we already have. 4. There is some functionality here that will likely upset some people because it's subjective I'm speaking specifically about type abstractions like Message (and friends). This is functionality that provides very little performance benefit from being compiled and causes all sorts of disagreement and bikeshedding over API details. Obviously there's the whole PSR-7 thing happening right now which will be subjugated to any bundled HTTP abstractions in the standard distribution. While I personally have a lot of real problems with the API the FIG people are pushing, we certainly won't be making friends by adding a de facto "standard" HTTP API to the language with which they disagree. These are APIs which should be carefully considered at a community level in a web-first language. Short of that kind of consensus, I don't see how it's a good idea to bundle that kind of API with the rest of the language. ... So, in summary: If I had to take all of pecl/http or none of pecl/http right now ... I would vote, "no," because while I want (and need) the capabilities from #1, I believe the associated drawbacks are too extensive to bring all the extra baggage into the standard PHP distribution. Thanks to anyone who read this phonebook of a mail all the way to the bottom! -Daniel --- ## #81405 — Michael Wallner — 2015-01-30T07:10:21+00:00 URL: https://externals.io/message/81403#81405 · In reply to: #81403 Hi Daniel! > > > Hi Mike :) > > I'd like to chime in on the discussion ... > > > 1. There is a lot of *really* useful functionality in pecl/http that IMO > should be bundled with the standard PHP distribution. > > This, to me, means things like parsing functionality that is conspicuously > absent in a web-first language like PHP. HTTP messages, cookies, header > parameters, multipart/form-data ... these are all standard HTTP elements > for which we have no compiled parsing capabilities in the standard > distribution. Adding this functionality in ext/http would be an instant win > for my own work and I'm sure for many others as well. Moreover, parsing is > the type of functionality that *really* benefits from being compiled as > compared to happening in userland. Finally, this type of functionality is > pretty vanilla and straightforward -- there is little room for stylistic > disagreements in APIs and implementations. No one is going to complain that > a multipart/form-data parser API is "zomg so bad I need to tweet my > frustration about #php right now." If it parses data how it's supposed to > it's generally good enough. > > These are the kinds of things that ought to be bundled with the standard > PHP distribution. They'd be a win for everyone and shouldn't realistically > upset or confuse anyone. > > > 2. There is some functionality here that isn't HTTP-specific and should > exist in other extensions. > > I'm talking specifically here about the Encoding\Stream things. In fact, I > had planned to PR essentially the same thing for ext/zlib between now and > the 7 feature freeze. This is functionality that isn't specific to HTTP and > belongs in ext/zlib, especially considering it relies on the zlib > dependencies in the first place. I don't think it's a good idea to do this. > It's missing functionality in another extension -- it should be PR'd and > included there. PHP is well-known for its perceived "lack of direction" and > this kind of overlap is exactly what people point to when they denigrate > the language. If we already have these extensions lets update them instead > of adding more extensions to cover holes in the existing ones. I'd > personally prefer to see new development/inclusions take the wide view of > the distribution as one whole PHP and not an incoherent mish-mash of > overlapping extensions. > > > 3. There is some functionality here that IMO belongs in pecl/ and not ext/ > > There are a lot of "extras" here. PHP's existing HTTP functionality is > already spread all over the map and bundling this additional functionality > certainly won't help to mitigate that. This ties in somewhat with my > previous point, but ... we have superglobals, ext/curl, > `file_get_contents()`, etc. Do we really need to bundle another extension > that depends on curl to make HTTP requests? Do we really need to bring in > two other pecl libs as hard dependencies for this? I don't really see > enough benefit here to muddy the waters in such a way. > > Beyond this, http requests are IO-bound transactions ... this is something > that can be done quite well (and is already) with existing userland > libraries without incurring significant performance degradation. I don't > see the need for all this extra stuff to add functionality that we already > have. > > > 4. There is some functionality here that will likely upset some people > because it's subjective > > I'm speaking specifically about type abstractions like Message (and > friends). This is functionality that provides very little performance > benefit from being compiled and causes all sorts of disagreement and > bikeshedding over API details. Obviously there's the whole PSR-7 thing > happening right now which will be subjugated to any bundled HTTP > abstractions in the standard distribution. While I personally have a lot of > real problems with the API the FIG people are pushing, we certainly won't > be making friends by adding a de facto "standard" HTTP API to the language > with which they disagree. These are APIs which should be carefully > considered at a community level in a web-first language. Short of that kind > of consensus, I don't see how it's a good idea to bundle that kind of API > with the rest of the language. > > ... > > So, in summary: > > If I had to take all of pecl/http or none of pecl/http right now ... I > would vote, "no," because while I want (and need) the capabilities from #1, > I believe the associated drawbacks are too extensive to bring all the extra > baggage into the standard PHP distribution. > > > Thanks to anyone who read this phonebook of a mail all the way to the > bottom! Thank you for taking the time to make your opinion public on internals, I appreciate. PHP should definitely take care to provide a reasonable API, but there’ll never be satisfaction for everyone. I think PHP is, and should be, a language where you’re more successful in getting things done, instead of having to do it right in one way only. This is not the end of the world for other HTTP components, see mysql/mysqli/PDO for example, but in my opinion it is the best we can do now for HTTP in PHP. Thank you, Mike --- ## #81412 — Tony Marston — 2015-01-30T10:08:27+00:00 URL: https://externals.io/message/81403#81412 · In reply to: #81405 "Michael Wallner" wrote in message news:BD568277-5A74-4A66-AC5D-173DA93FA8FB@php.net... > <> >I think PHP is, and should be, a language where you’re more successful in >getting things done, instead of having to do it right in one way only. Well said! I couldn't agree more. -- Tony Marston --- ## #82055 — Daniel Lowrey — 2015-02-06T16:44:35+00:00 URL: https://externals.io/message/81403#82055 · In reply to: #81405 > > […] the > > […] I may not have been clear before, but just to be sure ... I would really like to see the pecl/http RFC broken up into multiple voting options instead of one giant "yes" or "no" as per my previously mentioned concerns: > 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. > 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. > 3. There is some functionality here that IMO belongs in pecl/ and not ext/ > 4. There is some functionality here that will likely upset some people because it's subjective I also want to reiterate my feeling that PHP *does not* need to bundle yet another HTTP client -- especially one that brings other pecl dependencies with it. There's just no reason for doing this (other than API waffling). Performance is not a valid reason (we have ext/curl, which is fine if you want something that's compiled). Also, when you consider that HTTP resource traversal is more than adequately handled in userland already this addition just doesn't make a ton of sense to me. Let's bring the things that actually benefit from being compiled into the standard distribution; the rest should stay in pecl. If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 If this proposal is "all or nothing" then I have to vote "no" ... and it would be a shame to miss out on the beneficial portions of pecl/http :( --- ## #82386 — Michael Wallner — 2015-02-10T16:32:16+00:00 URL: https://externals.io/message/81403#82386 · In reply to: #82055 > > […] > expand the > > […] > > I may not have been clear before, but just to be sure ... > > I would really like to see the pecl/http RFC broken up into multiple > voting options instead of one giant "yes" or "no" as per my previously > mentioned concerns: > > > […] > IMO should be bundled with the standard PHP distribution. > > […] > should exist in other extensions. > > […] > because it's subjective > > I also want to reiterate my feeling that PHP *does not* need to bundle > yet another HTTP client -- especially one that brings other pecl > dependencies with it. There's just no reason for doing this (other than > API waffling). Performance is not a valid reason (we have ext/curl, > which is fine if you want something that's compiled). Also, when you > consider that HTTP resource traversal is more than adequately handled in > userland already this addition just doesn't make a ton of sense to me. > Let's bring the things that actually benefit from being compiled into > the standard distribution; the rest should stay in pecl. > > If you doubt that this is a solved problem in userland consider the > performance of my own 100% userland HTTP client demonstrated here > without the use of curl or any other extensions: > > https://gist.github.com/rdlowrey/54171625334670ccb9f5 > > If this proposal is "all or nothing" then I have to vote "no" ... and it > would be a shame to miss out on the beneficial portions of pecl/http :( While I think it's not a particularly good reason to vote "no", it may very well be a valid one; but I'm not conviced that splitting it up makes the situation any better. I really don't want to compete with the client you've written, but it seems this is the only thing you oppose to? -- Regards, Mike --- ## #82498 — Michael Wallner — 2015-02-11T22:16:09+00:00 URL: https://externals.io/message/81403#82498 · In reply to: #82055 > If you doubt that this is a solved problem in userland consider the > performance of my own 100% userland HTTP client demonstrated here > without the use of curl or any other extensions: > > https://gist.github.com/rdlowrey/54171625334670ccb9f5 I can replicate about 2.5s with artax/master on http://example.org, which is about the same pace like pecl_http. With pipelining enabled pecl_http/master peeks at about 0.7s, but what's the point? PS: I'm on an advertised 150/15 Mbit connection. -- Regards, Mike --- ## #82502 — Daniel Lowrey — 2015-02-11T23:26:29+00:00 URL: https://externals.io/message/81403#82502 · In reply to: #82498 > > > > […] > > I can replicate about 2.5s with artax/master on http://example.org, > which is about the same pace like pecl_http. With pipelining enabled > pecl_http/master peeks at about 0.7s, but what's the point? > > PS: I'm on an advertised 150/15 Mbit connection. > > -- > Regards, > Mike The point isn't *zomg this one thing I did in userland is super fast.* It's irrelevant. The point here is that HTTP transfers are an IO-bound operation and as such the benefit from compiling them is relatively small. Add that to the fact that we already have tools to do exactly this in the standard distribution (curl) and well-known, well-tested userland tools for any use-case you can imagine. In my opinion that adds up to not needing another way to do the same thing in the standard distribution. Who benefits from bundling another HTTP client? Why bring in two additional pecl dependencies for HTTP connections which *rarely* make sense to persist across web SAPI requests? Is there a plan to also deprecate ext/curl? These are questions that aren't resolved in a satisfactory way as far as I'm concerned. I honestly don't care that much, I just don't think "because we can" necessarily means "we should" when there's no obvious need for more of the same overlapping functionality. That's what pecl is for, right?