cURL.php process_response() returns no domain name for some Requests_Exception errors

[dfavor]

Some errors return a domain...

PHP Requests_Exception: cURL error 6: Could not resolve host: cdn.api.twitter.com in .../wordpress/wp-includes/Requests/Transport/cURL.php on line 422

Some errors do not return a domain...

PHP Requests_Exception: cURL error 28: Resolving timed out after 1510 milliseconds in .../wordpress/wp-includes/Requests/Transport/cURL.php on line 422

When no domain is returned, debugging this type of problem is impossible.

Request the function process_response() be rewritten to always return a domain for curl exceptions.

Thanks for your consideration to fix this bug.

[dd32]

Unfortunately these are the errors which cURL itself is returning, which sometimes don't include context of the request.

If you'd like to submit this upstream to ​Requests the library we're using for HTTP communication, you may be able to get the error messages context increased.

If you're seeing Requests_Exception exceptions, that suggests you're using the Requests functions directly within WordPress - please don't. Please use the ​HTTP API wrapper functions for it instead, which will allow plugins such as Query Monitory (IIRC) or Debug Bar (with HTTP add on) to monitor such requests and report/log when they fail (and what URL triggered the failure).

I'm marking this as invalid for now - as it's an external library, and it appears you're not using the WordPress APIs for it.

[dfavor]

​https://github.com/rmccue/Requests/issues/272 upstream bug opened.

[dfavor]

Upstream developer has basically said they won't fix this.

Very problematic, because the only symptom of this problem is WordPress slows to a crawl.

And clients think WordPress is slow which is incorrect. What is slow is some site being referenced + error message provide insufficient information to debug problem.

Likely fix is for someone in WordPress development to fork the Requests project + fix this bug + use the forked code in WordPress.

Or switch back to pre-Requests library code.

Both solutions are ugly + both solutions are better than having WordPress run slow due to an underlying library a developer refuses to fix.