WP_Http_Curl doesn't return errors for non-blocking requests

[SergeyBiryukov]

Noticed while debugging #23133.

If a server blocks local connections, WP_Http_Streams and WP_Http_Fsockopen return errors for both blocking and non-blocking requests:

WP_Http_Streams: Could not open handle for fopen() to ...
WP_Http_Fsockopen: "110: Connection timed out"

WP_Http_Curl, however, just returns an empty response, which makes debugging more difficult:
http://core.trac.wordpress.org/browser/tags/3.5.1/wp-includes/class-http.php#L1145

The actual error message that curl_error() returned was "couldn't connect to host".

23310.patch​ also closes the handle before returning from the function, which seems the correct thing to do, according to the example on ​http://php.net/manual/en/function.curl-error.php.

How long does the functions take to execute with that change? I mean, Does the function still return almost instantly, or does it sit around and wait for the HTTP connection to do something?

Replying to dd32:

How long does the functions take to execute with that change? I mean, Does the function still return almost instantly, or does it sit around and wait for the HTTP connection to do something?

AFAIK, curl_error() will only give you the connection errors when using non-blocking requests, so it's only an instant socket error. I haven't tested this thoroughly though.

Until we support proper non-blocking curl requests, this seems sane and brings it in line with the other transports. It doesn't appear to affect the response times (curl still parses the response before returning in either case, so we might as well use the output).

In 23607:

WP_HTTP: Return error responses from cURL for non-blocking requests. Contrary to popular belief, cURL's non-blocking requests are not exact non-blocking, we still wait for cURL to make the request before returning, so making this change aids in development debugging. Props SergeyBiryukov Fixes #23310