WP_HTTP may make a redirect request on an unsupported transport

[dd32]

When WP_HTTP determines which transport to make a request on, several checks are made - including filters and SSL checks.

Consider a scenario where Curl (or fsockopen) doesn't handle HTTPS url's, if a HTTP resource is requested, the checks will pass, and WP_HTTP_Curl will request the document. If that document however then redirects to a HTTPS resource, WP_HTTP_Curl will still try to handle the request, resulting in a failure.

Instead, individual transports should pass the request back to WP_HTTP so that it can process the request and dispatch it in the most appropriate manner.

This would also allow plugins which filter on the 'pre_http_request' filter to properly handle redirects, instead of only the initial request.

[dd32]

In order to achieve this, we also have to take Redirect handling out of PHP Streams (WP_HTTP_Streams) hands, and handle it ourselves.
We already do this for fsockopen and cURL, so this just means we can be 100% sure that each transport handles redirections the same.

[dd32]

In 23603:

WP_HTTP: Funnel all redirect requests through WP_HTTP::request() via wp_remote_request() to ensure that the proper transport is chosen for redirects.
This change also moves PHP Streams from redirecting internally, to us handling the redirections in PHP, which brings a more consistent behaviour between transports.
Fixes #23682

[dd32]

In 23608:

WP_HTTP: Fix returning WP_Error's on too-many-redirects after r23603 See #23682

[nacin]

In 24483:

Merge [23603] and [23608] to the 3.5 branch. This funnels all redirect requests through WP_HTTP::request() via wp_remote_request(). see #23682.