Community Documentation

"HTTP request status Fails" error

Last updated May 27, 2010. Created by Francewhoa on September 25, 2009.
Log in to edit this page.

Your Status report page located at admin/reports/status returns the following error

HTTP request status Fails
Your system or network configuration does not allow Drupal to access web pages, resulting in reduced functionality. This could be due to your webserver configuration or PHP settings, and should be resolved in order to download information about available updates, fetch aggregator feeds, sign in via OpenID, or use other network-dependent services.

Error screenshot. Under section HTTP request status

The most likely cause of this error is

  • You did nothing wrong. This is a well known issue in Drupal since around version 6.9. The community knows about it and is working on it. If you want to help fix this go to http://drupal.org/node/245990
  • A files format (character set) has been changed. For example when editing then saving your file your text editor changed the file format from UTF-8 Unicode to Latin1. Some text editor will change the file format without asking. Sometime inserting line brake or changing some characters.
  • A file got corrupted during transfer. For example while uploading a file via FTP.
  • A contributed module.

To fix this here are a few things you could try

For coders

Comments

php.ini

Check your php.ini settings. disable_functions shouldn't contain fsockopen. If you see in php.ini:

disable_functions = something, fsockopen, something

change it to

disable_functions = something, something
or
disable_functions =

It help's for me.

Of cause, it should also be
allow_url_fopen = On

And you can try to add
allow_url_include = On

HTTP request status

Where do I find this php.ini?

Firewall configuration can trigger error

If your site is sitting behind a firewall, verify the web server can send and receive HTTP traffic to itself, using it's public URL.

In this scenario, the host server has an IP address in a private network space (10.x.x.x). The Drupal site attempts to contact itself using the URL designated for the site, for example, www.mysite.com. The traffic leaves the host web site, through the firewall and returns back to the same host. Some firewalls will see this as an attack and block the packets.

The workaround was to add the site name to the /etc/hosts file on the host server to force the traffic back through the host server's network interface.

Example host file entry:

10.0.0.34 www.mysite.com

That did it, thanks

Thanks, I had that problem on some dev virtual boxes and this resolved it.

Updating the hosts file worked for me!

Some Details that might help someone else out:

I'm running an Ubuntu 12.04 LAMP machine as a production server (not a testing environment).

I had D7 installed and running while using a URL (my-drupal.example.com) that is a subdomain of our main website (which is on commercial hosted service). This all ran fine, never got the error. I started using a new subdomain to access the site (new-drupal.exmple.com) and still got no error.

Then, I messed up the Organic Groups upgrade from v1-v2 and decided to just start from scratch with a new DB and used the same code and everything on the site. This time, however, I set up the new site with the new URL (new-drupal.exmple.com) during the Drupal install process. And it kept throwing the error.

Adding the host name with the website URL fixed it up nice.

Now if I could only get the stupid vsftpd to work consistently and without file permission/owner issues, I'll be happy as a pig in poo.

__________________________________________________________
http://throk.net | @throk

Port Forwarding

Host OS = Debian Wheezy

Guest OS = Drupal7
+ Apache (running on 80)
+ Debian Squeeze
+ NAT Network Adapter (forward host port 8888 to guest 80)
(Because of NAT limitation on UNIX host, I cannot configure 80 to 80)

After change Network Adapter to Bridge, the error gone.

http://drupal.org/node/245990#comment-909263 gave me the clue

Update on fixes

A patch has been added to both D7 and D6 - see linked issue in article.

Present fixes are:

  • Webserver can actually access out: add line to settings.php, see link in article
  • DNS: see the hosts file fix linked in article
  • Firewall: preventing out going traffic, see comment above
  • SE Linux: if you're running SE Linux (common default on Fedora, Redhat... systems) it prevents access by default. setsebool -P httpd_can_network_connect=1 will permit httpd to access the network.
  • Something else is breaking it: follow disable modules process in article above

Views 3.0

I had this issue after creating a filter in a view. I made a view which showed all termsfrom a volcabulary (restricted about 10 terms) After that i created another filter NOT TO SHOW several of the terms and that was the problem. Maybe the filter came too heavy?
ps - sorry for commenting on "reply", did not notice "add comment" link.

Simple blocked by firewall

On one production server we got this issue all the sudden. Drupal only gave this error, but trying online tools from command line inside the server (over SSH connection) I figured out that all connections to outside world were blocked. This was due firewall misconfiguration in the server hall and had nothing to do with our server or Drupal installation. Just a note in helping to solve this problem, as it is very easy to try to use ping or similar command from your server to test if your network is fine.

Still mad confused =(

Okay, so I'm using vagrantup.com to set up an ubuntu VM to run a drupal site (to mirror dev and live environments).
I am running into this issue on Drupal 7.22 and I've tried just about all these fixes to no avail.
(I've already tried adding a line in /etc/hosts for the private ip:
10.0.2.15 www.testing.dev
and restarting apache, but it doesn't work)

With Vagrant (using VirtualBox behind the scenes), I'm using the recommended port forwarding of host:4567 to guest:80 so I can access my site via http://localhost:4567

Here is my /etc/hosts file on the ubuntu VM. Any ideas??

127.0.0.1       localhost
127.0.1.1       local.dev local precise32

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

If anyone wants to try to duplicate my Vagrant setup, let me know and I'll paste the contents of my Vagrantfile and bootstrap.sh

Bradezone :: for all your Brade needs

Page status

No known problems

Log in to edit this page

About this page

Drupal version
Drupal 6.x, Drupal 7.x
Audience
Programmers, Site administrators

Reference

Drupal’s online documentation is © 2000-2013 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.0. PHP code is distributed under the GNU General Public License. Comments on documentation pages are used to improve content and then deleted.
nobody click here