WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#40266 closed defect (bug) (invalid)

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

Reported by: dfavor Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7.3
Component: HTTP API Keywords:
Focuses: Cc:
PR Number:

Description

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.

Change History (3)

#1 @dd32
3 years ago

  • Component changed from General to HTTP API
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

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.

#3 @dfavor
2 years ago

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.

Note: See TracTickets for help on using tickets.