I got alerted to this by the HTTP Request Status item in the status report: Fail. Somehow drupal_http_request exits and takes the answer as being a failure. When doing the something with curl it works, although quite slow, if I compare with a fully baked drupal 6 site.
Furthermore I had to add
proxy_ignore_client_abort on;
to my nginx config so that curl completes the request. Otherwise it gives a 499 status code. I have a slow machine, but shouldn't drupal_http_request and curl -I give the same result:
1. With curl
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 08 Oct 2010 18:01:33 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=20
Vary: Accept-Encoding
X-Powered-By: PHP/5.2.12-2
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Fri, 08 Oct 2010 18:00:22 +0000
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
ETag: "1286560822"
X-Frame-Options: sameorigin
With drupal_http_request:
drush> php-eval 'print_r(drupal_http_request(url("http://maxwell:89", array("absolute" => TRUE)), array("max_redirects" => 0)));'
stdClass Object
(
[request] => GET / HTTP/1.0
Host: maxwell:89
User-Agent: Drupal (+http://drupal.org/)
[code] => 1
[error] => request timed out
)
If I pass the option 'timeout' => 60 it returns a 200. But I get an error:
drush> php-eval 'print_r(drupal_http_request(url("http://maxwell:89", array("absolute" => TRUE)), array("max_redirects" => 0, "timeout" => 60)));'
stdClass Object
(
[request] => GET / HTTP/1.0
Host: maxwell:89
User-Agent: Drupal (+http://drupal.org/)
[data] =>
Fatal error: Maximum execution time of 30 seconds exceeded in /home/appa/sites/d7/includes/database/database.inc on line 812
...
[protocol] => HTTP/1.1
[status_message] => OK
[headers] => Array
(
[server] => nginx
[date] => Fri, 08 Oct 2010 18:12:57 GMT
[content-type] => text/html; charset=utf-8
[connection] => close
[vary] => Accept-Encoding
[x-powered-by] => PHP/5.2.12-2
[expires] => Sun, 19 Nov 1978 05:00:00 GMT
[last-modified] => Fri, 08 Oct 2010 18:12:21 +0000
[cache-control] => no-cache, must-revalidate, post-check=0, pre-check=0
[etag] => "1286561541"
[x-frame-options] => sameorigin
)
[code] => 200
Could be of my slow machine. Albeit being plenty for developing with D6.
Comments
Comment #1
perusio commentedOops. Can't edit. Yes drupal_http_request exits because it times out, obviously.
Comment #2
shawnmeng commentedI have encountered similar issue before, I don't know if they are caused by the same factor. I got drupal_http_request error because my drupal 7 site base url didn't have a dns record. I added the dns record in host and the issue resolved.
Comment #3
perusio commentedHello,
This is a local dev machine. No DNS record. But I do have a proper /etc/hosts entry.
It correctly resolves to the loopback interface. I've tried all possible combinations:
1. IPv4: 127.0.0.1:89
2. 4to6: ::ffff:127.0.0.1:89
3. localhost:89
4. IPv6 only: ::1:89
The result is pretty much the same. But I do think that you're sending the correct path. Since the browser has its own DNS resolving layer and therefore any time of problem with domain name resolution will be mitigated. Right now I'm looking at drupal_http_request in D6 vs. D7.
Thanks
Comment #4
perusio commentedWell I've tried using fsockopen and setting the socket to non-blocking. It returns immediately but with an empty reply. The problem is in drupal 7 core. Somewhere. Could be something to do with my PHP version: 5.2.12.
Going to check devel to try to hunt the problem.
Comment #5
damien tournoud commentedThis *looks* like it could be related to #926426: system_check_http_request() causes deadlock on single threaded webserver.
Comment #6
perusio commentedWell no. It was the fact that I was using admin instead of the core toolbar. This is a personal preference UI thing.
This was so "obvious" I missed it :(
I will look into that issue. I have no problems whatsoever with nginx and standard php-cgi. I'm running on a very low-powered machine (1.3GHz Centrino with 1.5GB RAM). It's quite snappy.
Perhaps I can help other people sorting out their issue.
Thank you
Comment #7
Sergey Naumov commenteddeleted