Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#9998 closed defect (bug) (fixed)

cURL DNS Lookup timeout; Plugin and Update Download Fail

Reported by: carltonbale's profile carltonbale Owned by: dd32's profile dd32
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.7.1
Component: HTTP API Keywords: has-patch
Focuses: Cc:


This is an intermittent problem that seems to have been introduced in 2.7.1. The plugin browser works properly but plugin upgrades and installs do not. The following error message results:
"Download failed.: name lookup timed out"

Two work-arounds have been identified. One is to add "" to the "/etc/hosts" file. The other is to disable cURL using the "Core Control" plugin ( ) after activating the "HTTP Access Module 0.6" within Core Control.

The Core Control HTTP Access Module allows for testing of cURL. When the test is run, the following error message results: "An Error has occured: name lookup timed out"

When cURL is disabled in this module, plugin updates work properly due to reverting to an alternative method.

The issue has occurred on the following configurations:
Apache version 2.2.6 and 2.2.8
PHP version 5.2.5 and 5.2.9
MySQL version 4.1.22 and 5.0.41
Operating system: Linux

Here are links to posts discussing the problem in the forums:

Attachments (1)

9998.diff (3.6 KB) - added by dd32 15 years ago.

Download all attachments as: .zip

Change History (13)

#1 @ryan
15 years ago

  • Component changed from General to HTTP
  • Owner set to dd32

#2 @dd32
15 years ago

Unfortunately this is due to a buggy cURL Extension on some hosts, particually within europe i believe.

There is nothing wordpress can do to test for it it seems.

The only available option is to re-order the tests for the HTTP API, so that hopefully, cURL isnt used at all, unless absolutely required.

I'd be +1 for changing it to this order:

HTTP Extension

fsockopen was used extensivly before the HTTP API was introduced, and had few incompatibilities, while it wasnt always right.. it was more than often more reliable than cURL.

jacobsantos? Any feedback on that?

Setting to Future release pending a commitable patch and discussion of what the best approach is.

#3 @dd32
15 years ago

From jacobsantos on IRC:

04:02	jacobsantos		DD32: I'd say that with the recent problems to go for it.

04:03	jacobsantos	Damn, I wish, you know, stuff just worked to specs.

I'll make up a patch later to re-order them a bit.. well.. at least bump curl down.. Might leave streams/fopen above fsockopen, Unsure on that bit still.. Most people seem to find it works fine once they disable curl..

#4 @jacobsantos
15 years ago

I'm contemplating writing patch that allows for disabling the transports from inside WordPress. The goal was to allow "easy" disabling of the transports, but no one really wants to seem to write the plugin themselves.

DD32's plugin kicks major ass, but I think it might be cleaner just to include that piece (albeit, not disabling the last one, whatever it may be).

The reason I don't like fsockopen to be used, is that there is a great deal more overhead, since a lot of what is implemented by the other transports internally had to be implemented in user land. This is going to be inherently slower than those transports that do it in C PHP extension.

Well, it seems that doesn't prevent bugs from being in the other extensions.

#5 @dd32
15 years ago

I realise fsockopen has higher overhead.. But its very minimal for such a rarely used set of code..

One of the bug-inducing problems of the other compiled methods, is that WordPress itself cant implement everything correctly itself, WordPress is at the hand of the curl developer, the php curl extension developer, the webservers curl configuration, etc, fsockopen, on the other hand, if we cant open a connection, thats it! but if the connection does open, WordPress can do everything straight up as it see's fit.

Perhaps a hidden page inside WordPress (like the options.php page) for certain "Advanced functionality" such as disabling transports could be used? yeah.. i know.. plugin material.. but its nice to have rare things that are needed sometimes..

#6 @Denis-de-Bernardy
15 years ago

  • Milestone changed from Unassigned to 2.8

15 years ago

#7 @dd32
15 years ago

  • Keywords has-patch added; cURL dns lookup plugin download fail "name lookup timeout" removed

attachment 9998.diff added

  • Patch moves curl to last position in the preferred rankings.
  • Patch moves fockopen to 2nd position due to higher compatibility
  • Updated PHPDoc

#8 @dd32
15 years ago

note: With that patch i'm having fsockopen difficulties with timeouts.. Apparantly the timeout being passed to fsockopen is too short, it times out after 0s attempting to connect to localhost (Thats for core update checks)

fsockopen ( 'localhost', 80, 0, '', 0.01 )

#9 @azaozz
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [11524]) Preferred transport: move curl to last position and fockopen to 2nd position due to higher compatibility, props DD32, fixes #9998

#10 @dd32
15 years ago

Ignore that final comment, It wasnt due to the timeout, but rather 'localhost' + IPv6 host entry. see #10045

#11 @automattor
15 years ago

(In [11631]) Revert [11524]. curl has its problems, but so does everything else. see #9998 fixes #10104 for 2.8.1

#12 @dd32
15 years ago

Changed 2 hours ago by automattor

We've got sync issues again...

Yeah, +1 for reverting in 2.8.1 branch, -1 to reverting in trunk, Get some testers on it and actually fix the transport with issues.. Chances are, someone else will fall victim to it in future if curl isnt available.

Note: See TracTickets for help on using tickets.