Voting starts in March for the Drupal Association Board election.
Drupal's current outgoing-HTTP capability is, to be polite, minimal. We have one small function with a lousy API that can do basic requests, but that's it. If we want to be serious about web services we need strong bidirectional HTTP support.
Issues depending on a better API for HTTP requests (check these and move down to follow-up if correct, close if redundant now).
- Put AdvAgg in core
- Can be fixed with something like Background Process
All of these need something better than drupal_http_request() in order to be done well.
Writing a solid HTTP client is hard. Fortunately, there's plenty of existing ones out there that we can leverage, just like we pulled in Symfony.
Mikeytown2 did some extensive research into existing libraries, and the end conclusion was that Guzzle was the most full-featured and capable option available. It's only missing feature was asynchronous HTTP requests, which the author, Michael Dowling, added based on our feedback months ago.
The primary concern expressed about Guzzle is its size, which was decidedly not-small. (Multiple megabytes.) The size is justified for a fully capable HTTP client, because HTTP is complex, but not everyone was comfortable with a vendor library that was 2-3 MB in size.
Based on those concerns, Guzzle has been refactored in 3.x to be a suite of components, much the same way Symfony is. That allows us to just pull in 3-4 base components for core, and contrib modules that have need of the more advanced Guzzle components can pull those in when they need to. Problem solved.
The other concern was that Guzzle requires cURL, whereas drupal_http_request() does not. However, based on feedback so far it appears that cURL is far more common than it used to be, so making it a requirement for outgoing requests is not an onerous requirement. Arguably it's less onerous than Drupal's performance requirements, which effectively mandate APC already. The recommended resolution here is "meh, OK, you need cURL. Such is the modern web."
Therefore, Guzzle. Let's do.
- Get a green light from Dries on this issue. Dries?
- Add the necessary Guzzle components to core via Composer. Convention has been to do this in a separate patch from this issue to keep patch size down.
- Expose Guzzle to core via the Container.
- Replace calls to drupal_http_request() with Guzzle. (Don't bother wrapping an extra layer around it. There's no benefit to doing so.)
User interface changes
drupal_http_request() goes away, instead you use Guzzle directly. Other systems like Simpletest could be refactored to use Guzzle's browser as well, but that's for follow-ups.
PASSED: [[SimpleTest]]: [MySQL] 49,012 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Repository checkout: failed to checkout from [git://git.drupal.org/project/drupal.git]. View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1447736-157-adopt-guzzle_0.patch. Unable to apply patch. See the log in the details link for more information. View
PASSED: [[SimpleTest]]: [MySQL] 48,122 pass(es). View