consider disabling HTTP transport after multiple failed requests

[dd32]

There has been a number of reports over the lifespan of the cURL HTTP transport failing with an error during upgrades:

WP HTTP Error: name lookup timed out

This is a common error from cURL on badly configured installations (specifically, IIRC it lacks DNS Resolving in cURL, sometimes it just required an extended amount of time to resolve, others, it simply can't resolve)

Like we do with fsockopen() I think it'd be worth disabling the cURL transport for x hours when it hits this particular error condition..

Related threads: ​http://wordpress.org/support/topic/dashboard-issues-rss-error-wp-http-error-name-lookup-timed-out and ​http://wordpress.org/support/topic/plugins-update-failure Both old threads, so this may only affect a PHP4 version of cURL.. For tracking purposes, I've finally created this ticket.

[hakre]

Looks like a configuration issue a host and not a defect with wordpress.

[nacin]

Restoring dd32's keyword until appropriate feedback is given.

[dd32]

Looks like a configuration issue on a host and not a defect with wordpress.

Yes, That is the exact problem. The transports are designed that it uses what is available on the host, If WordPress does not take into account a transport failing, we end up in a situation where Updates Notices do not flow through amongst other things. It's in the best interests of WordPress users to protect ourselves against these issues.

[SergeyBiryukov]

There are some similar threads on local forums too.

[dd32]

With a dwindling number of transports, and transports which we can increasingly actually rely upon, this isn't as needed as it was 2 years ago.