#9998 closed defect (bug) (fixed)
cURL DNS Lookup timeout; Plugin and Update Download Fail
Reported by: | carltonbale | Owned by: | dd32 |
---|---|---|---|
Milestone: | 2.8 | Priority: | normal |
Severity: | normal | Version: | 2.7.1 |
Component: | HTTP API | Keywords: | has-patch |
Focuses: | Cc: |
Description
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 "72.233.56.139 downloads.wordpress.org" to the "/etc/hosts" file. The other is to disable cURL using the "Core Control" plugin ( http://wordpress.org/extend/plugins/core-control/ ) 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:
http://wordpress.org/support/topic/231500?replies=5#post-948036
Attachments (1)
Change History (13)
#3
@
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
@
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
@
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..
#7
@
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
@
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 )
#10
@
15 years ago
Ignore that final comment, It wasnt due to the timeout, but rather 'localhost' + IPv6 host entry. see #10045
#12
@
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.
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:
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.