I've just installed Drupal6 on my school webserver ad the Status report reveals this configuration 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.

I gather it is a server configuration problem but my searches have revealed nothing to help me fix it.

Can anyone help me solve this one please?

Comments

Pablofiesta’s picture

I have the same problem. On the same server I have 5.7 installed for a different site with the Status Report module that works flawlessly, no errors or performance issues. When I active Status Report in 6.0 admin pages crawl to a halt. Any ideas, anyone?

mmcnamee’s picture

I had this problem due to the server Drupal was running on trying to access "itself" via the DNS entry, pointing at the external IP. The firewall blocks this, and the workaround is to put an entry in your /etc/hosts file or Window's Hosts file for the INTERNAL IP, with the same hostname Drupal is configured with. Restart apache, and all should work ok again.

Mark

allella’s picture

DNS was the issue for me. I was getting the "HTTP request status" error, cron jobs not finishing, Update Status not updating.

I believe the message was being generated by fsockopen not resolving the DNS for updates.drupal.org.

In this case, update.fetch.inc calls drupal_http_request() which by default checks http://updates.drupal.org/release-history for updated module information.

This started happening after some of our Linux server were migrated to a new data center with new IP addresses. I believe the name servers stopped properly resolving the external domain names, like updates.drupal.org. For instance, from an SSH command line a ping of the update server would fail.
ping update.drupal.org

A quick, temporary fix was to add the following line to the Linux /etc/hosts file via SSH.
140.211.166.6 updates.drupal.org

In the end, correcting the nameserver IPs in /etc/resolv.conf so they resolve any external domain name seems to be the real solution. Adding 140.211.166.6 to the /etc/hosts only solved the problem for Update Status module since modules like Feed Aggregation, OpenID, and any other modules that call outside servers all rely on the web server's NS servers resolving domain names to IP addresses.

Once the web server successfully pinged updates.drupal.org, I ran cron.php (not sure if this was necessary) and the manual Update Status checks started working immediately, the HTTP request status went away, cron started running, etc.

This could explain why some people's site works fine one day and fails another. Name server configurations or locations might be changed by the hosting company or the name server(s) might just be failing to resolve addresses some days.
OrangeCoat.com

afagioli’s picture

please confirm we need

update.drupal.org

or

updates.drupal.org
gwences’s picture

the hosts file trick worked

JoeYEI’s picture

I had a site that was working fine on a server that hadn't been rebooted in about a year. After the reboot, I started getting the "HTTP request status fails" error. I edited my hosts file to add www.example.com and example.com to point to 127.0.0.1, then I restarted Apache, cleared my Drupal caches and waited about 30 minutes and it started working again.

Thanks for the suggestion!

Marquis’s picture

Hi ,

I too have the same problem. I tried contacting my webhost, but they need more details regarding php requirements and modules that are being affected by this error.

After searching, I've noticed that no solutions are ever revealed. Is this not a common problem?

Marquis’s picture

I think there is a security feature in cpanel that is preventing web apps from accessing other web pages.

I'm quite the novice, but somehow, I recall seeing such a feature ... I think :|

Anyone know of a way to test if that may be the problem, then it might be easier for me to diagnose my problem.

:(

sunsetco’s picture

I, too have the same problem.

However, I noticed every once in a while it works fine. Not sure why. Seems to make a difference if I go into the Control Panel on my host account and run the "Cron" job manually. After that the Status report is all green!

Could it simply be a time-out error that Drupal is interpreting as a refusal for the HTTP Request?

peregrina’s picture

yes, it could be a time out: set_time_limit() has been disabled for security reasons in /x/includes/common.inc on line 2511. something like that was in red in header... maybe runing cron does help im using d6

Slim Pickens’s picture

There is a discussion on this http://drupal.org/node/7881.

Changes need to be made to the /includes/common.inc code to enable http connection through a proxy requiring authentication. There are some examples of what people have done to get around this problem.

I haven't succeeded yet with Drupal 6 as I'm getting syntax errors with my first attempt at modifying common.inc, but the instructions for use aren't clear. I'll let you know if I get it fixed. If anyone else figures it out maybe they can comment here.

Meanwhile there are calls for this proxy authentication issue to be included in core as there are many drupal hosts on intranets behind firewalls and proxy servers.

But at least we know where the solution lies.

zilla’s picture

see http://drupal.org/node/50912 for patch...(edit: nope, see my post down 2 below about web host related issues)

zilla’s picture

okay, so i'm still seeing the error - have NOT applied that patch because i don't know how to apply patches (can i just browse cvs and download and overwrite most common file (common.inc) ? then run update.php? no idea what i'm doing there or how to command line patch diffs...

at any rate, i still see this error - everything was totally fine for days, mods were telling me about updates and all of that...then i enabled (today) aggegator and tagadelic and the error is appearing (against aggregator most likely, can't process the http request) but in turn it can't check anything drupal (including mods and so on)

so i hit 'run cron manually' and it cleared up - but then came back within hours when running cron automatically, and now again won't fix at all when running cron manually - and of course this means no status updates...and no use of aggregator, and no openID if desired...bummer.

EDIT: came back to edit this post. i installed 6.1 which incorporated this patch but the issue persists...no idea what is causing this and it is now ruining an otherwise perfect drupal install! aggregator is dead, update status is dead (but was working before) and network services like openID are also dead...

does **anybody** have any idea how this might be fixed? i'm on a hosted service (grid) from mediatemple and have never had issues like this...

zilla’s picture

sad but true, please read this post i put up for explanation for a number of drupal users in typical web hosting environments:
http://drupal.org/node/227791

fiade’s picture

I had the same problem but my allow_fopen_url at php.ini was set to "on". I discovered that, if I remove the "offline status" of the site, the "http_requests status fail" message disappears. Tyr it!

zilla’s picture

yes, i can confirm that this works with mediatemple, probably others as well...

ekerazha’s picture

I can confirm this.

marius.s’s picture

Same here.
I did put the site back online, ran cron, and the error went away

tasigurl’s picture

How do I remove the "offline status"?

How exactly do I fix this problem?

Slim Pickens’s picture

Some interesting aspects of this problem have been unearthed - thanks to all who have contributed.

I'm pretty sure that my particular issue is that my web server is behind a firewall which requires proxy authentication.

When I built the web server I was able to configure apt-get for updates using a .conf file:

Acquire::http::Proxy "http://username:password@proxy.myupstreamproxy.net:8080";

and it works like a charm.

What I need to know is how can I do something comparable for my Apache2 PHP5 webserver when it needs to access another website (such as Drupal updates)?

I've scoured Google but have not found anything yet.

Anyone have any ideas?

Thanks

vonslatt’s picture

My install is on a fresh RHEL5 box w/ apache2 & Drupal 6.1

My default php.ini already had "allow_url_fopen = On"

No external firewall, but I used system-config-securitylevel to close off all but http & ssh

Since this is a development site I had a password stanza in my .htaccess thus:

AuthType Basic
AuthUserFile /var/www/passwd/htpasswd
AuthName "Cast and Crew Only"
require valid-user

Commenting these lines out fixed the issue and my status report is now all green.

Jake.

benkant’s picture

... if your drupal installation uses the same hostname as your server.

We have a machine whose name is blah.example.com. We have installed a drupal site for blah.example.com, eg sites/blah.example.com

When system_check_http_request() runs, it tries to fetch http://blah.example.com/admin/reports/request-test and match it to the data received from an output buffer request of the same URL.

This will fail because fsockopen() will resolve blah.example.com to 127.0.0.1 and give you something very different to the output buffer data. Trying to fetch http://127.0.0.1/admin/reports/request-test will result in a 404 because this won't hit drupal.

So drupal_http_request() will think it can't ever access anything, set the drupal_http_request_fails variable to TRUE and never try again.

The reason this is false (in a way) is that although you won't be able to access drupal running on localhost, it will be able to access machines elsewhere.

Using the HTTP proxy patch works (http://drupal.org/node/7881) because the proxy server fetching the url will resolve your machine name (blah.example.com) to its regular IP, and not 127.0.0.1 therefore hitting drupal and getting the data it was after.

As for how to resolve (pun intended) this issue, you can:

a) Not have your drupal install be the same name as your physical machine. Set an alias in your DNS to point to your server, and use that host name as the drupal install (ie, www.blah.example.com)
b) Use the HTTP proxy patch and use a proxy
c) Patch system_check_http_request to use a URL not on your drupal install as a test. It has to be static content and should be short and dependable as always being there. Perhaps drupal.org should host a file like this.

Other than that I don't know.

This obviously isn't the only reason why you would be getting this error. It only applies if your drupal installation uses the exact same name as your server.

age3141592’s picture

Also have a look at http://drupal.org/node/245990 which confirms the system_check_http_request() idea and has some instructions to work around it.

esmartwave’s picture

If you add a record into /etc/hosts or a DNS alias pointing the name of your development site to the given or manual IP address and not 127.0.0.1, it resolves the issue.

For those that use hosted solutions, the proxy would probably be a good bet, unless your hoster has a slick DNS management tool.

alphex’s picture

I have a server with the hostname "foo.blah.tld"
I have drupal installed at "http://foo.blah.tld/drupal/

I added
127.0.0.1 foo.blah.tld

to my /etc/hosts file, and it worked.

] duran goodyear
] alphex information solutions, llc.
] http://alphex.com

Anonymous’s picture

to quickly...
not thought about...
the same procedure is every year... ;o)

rickso’s picture

I'm having this problem on localhost. I have three feeds set up on Feed Aggregator, and one of them came through one time and the other two never did. I ran cron manually, and I still get the error.

What can I do to fix this on localhost?

Thanks.

NikLP’s picture

I had this problem for hours. Nothing seemed to work. I couldn't fix ongoing problems with my aggregator setup (this all started after I had properly configured cron).

I cleared the cache and turned off aggregator module and have no more errors. I have yet to spend any time looking into the aggregator problem.

stefan57’s picture

I also had this error on my Vista / Localhost test drupal.

I just removed the write protection on /windows/temp and then it worked fine again without any errors.

Sborsody’s picture

I had this problem on Drupal 6.4 hosted by SiteGround. After reading the others here, here is my experience and what fixed it.

1) My cron wasn't really running and I ignored it because my site isn't live yet.
2) While under development, I've got my site password protected using HTTP Auth.
3) Yesterday I started having this error message about the server being unable to access HTTP.
4) I disabled HTTP Auth, ran cron manually, flushed cache, re-enabled HTTP Auth and it works now.
5) I modified the cronjob to use HTTP Auth so it would run :)

I believe because cron didn't run for so long, Drupal locked itself (as someone else said here because of a timeout). Running cron manually with HTTP Auth turned off made it reset itself. It works again too with HTTP Auth re-enabled.

NikLP’s picture

What specific Auth stuff are you using? I have a load of stuff like "Allow from xx.xx.xx.xx" in my htaccess at the top, which could of course be my specific problem. Are you using something similar to this?

Web Design & Development in Nottingham by Kineta Systems

Sborsody’s picture

The kind of authentication available in .htaccess where the user has to enter a username and password.

If you're specifying access based upon ip addresses in your .htaccess file, make sure you are allowing connections from the localhost, 127.0.0.1.

NikLP’s picture

I did that, but it doesn't work - cron stopped running again, with this:

Order deny,allow
Deny from all
Allow from my.home.ip.address
Allow from 127.0.0.1

Any takers? I'd really like to see something as simple as this working all the time.

Sborsody’s picture

SiteGround made a change to their service that allows individual accounts to pick which php version to use. That became one of the sources of my problem I believe. After I contacted them about the HTTP Request issue they changed the php version on my account. When they did that, Drupal started telling me that register globals was on, even though it should have been off per the standard .htaccess file included with Drupal. I should have looked at the PHP info output earlier just to compare. I think their php settings for the new available versions were not correct somehow. I had an additional issue where the server would tell me the POST method was not allowed after I tried changing something on my site (clearing the cache). I walked away from the computer and came back later and things were cleared up. I'm not sure if there was something funny going on with the PHP version switching and the Drupal cache.

As I said, things appear cleared up, except for this one last thing. When I try to go to admin/settings/error-reporting the server sends me a raw file of type "application/x-httpd-php52" instead of handling it correctly (.htaccess has the line AddHandler application/x-httpd-php52 .php .php5 .php4 .php3). I can get to that page correctly if I use the real url instead of clean urls (i.e. index.php?q=admin/settings/error-reporting). Maybe this is an issue I should open...

Flying Drupalist’s picture

I'm very suddenly getting this one too. Out of nowhere... :(

Krummrey’s picture

Never had it before.

Paulo Rodrigues’s picture

My apache config blocks access to /admin/ or /user/ from anywhere else except my own static IP address.
Funny thing is this was working, only complained today.
I added the server local IP address to the allowed IPs and the error is gone now.
Thanks to benkant for explaining what happens, so I could find out what I'd done wrong and fix it :)

joric’s picture

It happened when I used a fake server name on my destop (via /ets/hosts on the desktop machine).
You just have to make sure that server knows that name too (i.e. add it to the server's /ets/hosts).

btrower’s picture

Just wanted to make clear that adding the name of the host (or virtual host in my case) to the /etc/hosts file definitely fixed this problem. I was stopped at the screen during installation and it stayed there. It worked immediately as soon as I added the domain name to the hosts file.

If anybody is reading this, it is one of my design notes for my next release of software that something like this should be managed directly by the software. If there was a place to spit out the message, then there can be code behind that to contact this site, lookup the error/state and offer the solution(s) directly. If unresolved, it should remain open until closed and be re-opened if the error continues to occur.

I had to create an account here, just to enter this comment. Given that I was installing the software, it should have allowed me to give feedback directly against the ticket.

Even though the above sounds difficult, it is not nearly as time consuming as all of this stuff. When I finally get near release code of the new system (I am porting an existing system), I think I will release the design notes on this so others can follow suit.

Aren Cambre’s picture

This is my situation, and it fixed it for me. Opened #692990: "HTTP request status" always unsatisfied with hosts-defined domain name.

mrSjoerd’s picture

I found this sollution on the drupal site (I forgot who originally posted it):

go to: C:\Windows\System32\drivers\etc
and open "hosts"

put an # in front of ::1

This did it for me.
I use Windows Vista.

sender’s picture

Thanx, this worked for me. Running on Vista x64.

This also seems to have sped up accessing /admin (which was really slow).

mechler’s picture

I just wanted to put another note here saying that commenting out the ::1 line in the Vista hosts file fixed this for me. I was having problems with this on my laptop for quite a while and had just resorted to booting in to linux to do this all the time. Being able to pop over to a test server while mid-flight and try something that pops into my head without all the slow-down and hoop-jumping is fantastic. Thank you so much for this note. It all makes sense now!

Web Developer, Iowa State University College of Veterinary Medicine

pgmillion’s picture

I had looked at all my local Windows firewall configs and router configs with no luck. This edit to the hosts file fixed it for me. Thank you very much!!

dr.fang’s picture

Thanks, mrSjoerd. This works on my Vista, too. Does anybody know what's the use of this "::1"?

hoobuba’s picture

That is IPv6 localhost address.

Here is how to disable it - if you are not using it.
http://www.mydigitallife.info/2007/09/09/disable-and-turn-off-ipv6-suppo...

Cheers,

Milos

ron_s’s picture

Milos, I tried to disable the IPv6 first, but this didn't seem to do anything. IPv6 is associated with my network card, and I'm running localhost, which I think should have no connection to the network card.

I had to comment out the ::1 line in the hosts file as noted above to get it to work. Has anyone else been able to fix the issue by just disabling IPv6 in Vista Network Connections?

hoobuba’s picture

Worked for me - Vista 32/XAMPP

mljhilton’s picture

This has worked a treat on localhost. However, my live site is hosted on Unix, so I need the equivalent solution for Unix.

Matt.

JayNL’s picture

Thnx, perfect solution. Smooth, fast admin and no more nags about disfunctional features.

krhines’s picture

Adding # in front of ::1 resolved the 'fail' for me. Thank you!

I did this through Windows Explorer and had to set the settings to show extensions as I made the edits in Notepad, and it automatically added a .txt. When I set it to display the settings, I could rename the file to get rid of the .txt.

terkhorn’s picture

Hi,

This was an annoying little problem for me on Vista 64 bit. By commenting the ::1 line in Windows/System32/drivers/etc/hosts, it was resolved

Thanks
Felix

JVA-1’s picture

Did the job on Windows 7 + XAMPP
Thanks

chucklima’s picture

One other thing to check on Linux.

Make sure bind-utils is installed, it has all the nifty DNS tools - host, dig, nslookup, etc.

onetwoten’s picture

I was having issues with the http request status failing as well.

I fixed it by editing the windows/system32/drivers/etc/hosts file and adding "127.0.0.1 localhost" to the bottom of the file (in vista open notepad as administrator).

I suppose you could also just uncomment the same thing towards the top of the file but I wanted to leave the original file as intact as possible.

Hope that helps!

Jeff Swanson
GardenGnomeWorld.com

MrPaulDriver’s picture

I'm New to Drupal and have been learning on a Windows XP system under localhost - without any difficulty.

Today I setup Drupal on a laptop running Windows 7 and ran into to this http problem being discussed here.

Jeff's fix above worked for me.

Is this problem just a 'feature' of newer versions of Windows?

---
Paul Driver
www.easable.uk
Ilkley, West Yorkshire, UK

mjlF95’s picture

This solution also worked for me on Windows 7 32bit to fix the HTTP request status fail issue. I'm running locally on XAMPP right now FYI.

cyberswat’s picture

A quick solution to remove the error message is to edit the following line in system_check_http_request() inside of system.module:

$result = drupal_http_request(url('', array('absolute' => TRUE)));

It is trying to do an http request to the drupal instance being run but is failing because it returns a really weird status code... insert a website you can resolve to and it will remove the error ... like so:

$result = drupal_http_request(url('http://drupal.org', array('absolute' => TRUE)));

This is definitely not the "Drupal way" of fixing the problem, isn't in a patch form, likely isn't attached to the correct issue, and doesn't flow with the Drupal social/political structure but it lets me continue my work ... I would recommend removing your edit to this file when you are done.

makatozi’s picture

I used cyberswat's less traumatic solution after trying many of the other "fixes". This one works for me. I understand the "Drupal Way" of fixing problems but this problem was really dragging me down. I have done dozens of Drupal installs and NEVER seen this issue before. This particular install was completed using XAMPP 1.7.1.
Thanks cyberswat!

byant’s picture

it didn't work for me, the problem is still exist

MbahGondrong’s picture

Dude your fix works marvellous, thanks a lot.

rudders’s picture

updated /etc/hosts on my vmware image (CentOS 5.2) so it knew it's own name and hey presto!!!

willow315’s picture

I'm running Windows XP Pro and have installed XAMPP, running MySQL 5.1, and Apache. Have just installed Drupal 6.10 and done a few module updates...Can't resolve the status error HTTP request status Failsl.....this has been plagueing me from the beginning. I can't seem to get off the ground here.

Can someone please assist me with suggestions appropriate to running this installation on my local machine as a test environment in XAMPP.

Thanks, WCW

r_honey’s picture

The #::1 hack worked for me (Vista 32).

However, I believe the Drupal team should have a serious look at the issue and resolve it in a more appropriate fashion than editing hosts file, or other options mentioned above.

Drupal Centric’s picture

You could try the module that worked for me: http://drupal.org/project/http_request_fail_reset

meldog1’s picture

I run Drupal from my home on an internal LAN (non-routable ip's) and was receiving this error. My remedy was to add the external/internal hostnames to the /etc/hosts file: (I used sub domain's for my site)

XXX.XXX.XXX.XXX sub.domain.com
XXX.XXX.XXX.XXX sub2.domain.com

XXX.XXX.XXX.XXX = internal IP address assigned to your web server/virtual host configuration for both domains above.

sub = Is the domain that provides external access to my webserver from the internet ("A" record that points to the WAN side IP of my DSL Modem)

sub2 = Is the domain that provides internal access for my LAN

Hope that helps!

Matt

crazyg77’s picture

Hello there!
I solved the issue on Vista by updating C:\Windows\System32\drivers\etc\hosts and C:\Windows\System32\drivers\etc\lmhosts.sam to contain the following mappings:

127.0.0.1 localhost
xxx.xxx.xxx.xxx localhost

where xxx.xxx.xxx.xxx is my static IP.

I also installed the module "Http Request Fail Reset" on drupal (version 6), see http://drupal.org/project/http_request_fail_reset

I hope it helps.

smcelhinney’s picture

Thanks for all your help with this guys, Id just like to add something that may be overlooked (because I overlooked it!). When adding entries to /etc/hosts to resolve DNS issues, make sure that you include root and sub-domains, example

127.0.0.1 example.com www.example.com

I forgot to do this, and only dawned on me recently. It also explained why this was working intermittently, as sometimes users would access my site via one or the other. In Apache conf, they both resolve to the same vhost, using ServerAlias, but I needed separate entries to help DNS along.

Hope this helps someone else.

faux_codex’s picture

thanks much.... after reading the last few posts of this thread.... i just (as in this was ALL i did) added:

127.0.0.1 localhost
127.0.0.1 example.com

to C:\Windows\System32\drivers\etc\hosts

running win7 and WAMP... added bonus, not only do i not get the error any more, i don't get the "sluggishness" when i click "Administer" anymore (which is probably kinda obvious, in that if it's not hanging on the http request... it would be faster... duh... sorry it's late here)

thanks for all the help and hopefully this helps somebody else

f_c

myownsummer’s picture

Phew. I hope this is the worst Vista has to offer. And I know I am being too optimistic.
Thanks for the fix!

Chirul0’s picture

We have an internal development box w/ 1 ip, using internal domain names (site1.localdomain.local, site2.localdomain.local).

Adding:

127.0.0.1 site1.localdomain.local site2.localdomain.local

Fixed the HTTP request fail issue.

sgriffin’s picture

Trackback, accidentally showing third party content via ssl can cause this. Like youtube videos.
http://drupal.org/node/227791#comment-2172748

mkassets’s picture

Another possible scenario for this error is when you are using the Secure Pages module but your PHP was compiled without --with-openssl. That's what it was in my case.

When using the Secure Pages module your admin pages (including the status page) will typically be protected by SSL, and Drupal will test the connection by fetching the https://yoursite.com. Even if SSL is supported in your Apache and https://yoursite.com works perfectly in your browser, the test request may fail when attempting fopensocket with the ssl:// schema if php was compiled without the openssl support

vincentdemers’s picture

In my case I had put a trailing slash in the "Secure Base URL" and "Non-secure Base URL" fields in Secure Pages admin. This made it create the HTTP request staus fails error.

kuschelhummer’s picture

Hi,

if you are in my position (installing Drupal on my local windows machine for development), you might as me be perfectly happy by using 127.0.0.1 instead of localhost. Can help on all Windows environments.

replace http://localhost/vanilla1/ with http://127.0.0.1/vanilla1/

As this is an absolutely no production site, I could not care less about the adress.

nzeesheikh’s picture

Hi,

I been having this problem for long time, and finally thought to fix this issue for once in all.

This is usually happening to DNS resolver issues with your router/ISP. To do a quick fix please follow these steps.

Windows Vista/Windows 7

- Run Notepad with Administrative rights
- open up the C:/windows/system32/drivers/etc/hosts
- add a following line to it and save the file.

127.0.0.1 localhost

If the above solution does not work, then add third DNS IP 127.0.0.1 address in your connection settings.

JoshuaWarrior’s picture

I have had this issue and it has caused me to lose days of work. Here it is, and oh, by the way, it fixes serveral other issues. I know this "Fix" was poster previously, but I thought it might be nice to point out that it fixes serveal symptoms:

If you are a running a local Windows Apache/PHP/MySQL dev environment and encounter a problem where you:
1) Cannot open the /admin node (it’s blank and inaccessible); or
2) Get the “HTTP request status – fails” message; or
3) the “Apache log error about the favicon.ico file not existing;
4) Any combination of the above, try this:

If in the C:\windows\system32\drivers\etc\hosts file there is a line:

::1 localhost

then this fix is for you!

Comment out this line ("#::1 localhost", save the file. All works perfectly!

In addition, the persistent:
"HTTP request status - fails" error and...

Apache log error: [Thu Mar 18 09:08:17 2010] [error] [client 127.0.0.1] File does not exist: C:/wamp/www/favicon.ico
all go away.

Give it a try.

jjmackow’s picture

I tried Joshua's suggestion but the issue continued until I added:
127.0.0.1 [virtualhostname]
where
[virtualhostname] is the actual name of my virtual host.

cheers,

kev

tmsnhien’s picture

After turning off firewall's rules for Apache. It runs well.

9ler’s picture

open C:\Windows\System32\drivers\etc\hosts and edit in notepad

before fixing last part of my C:\Windows\System32\drivers\etc\hosts (windows 7 x64) looked like this:

# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost

After fixing it:

# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
# ::1 localhost

the fix workes after you refresh your page

Edit: just noticed that Jeff Swanson postede this some where in the middel of the tread. sorry for reposting it :/

ru.meta’s picture

Also works for me on 32-bit version of system.

Observer8’s picture

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

redrider’s picture

Unfortunately for me, none of the above "fixes" have resolved this issue.

I am using wampserver to try to do some theme work

steel-track’s picture

I rebuilt my Apache installation with OpenSSL and it fixed the HTTP Request error message. If you are using Secure Pages and getting this error, I would check for OpenSSL in your Apache installation, and also make sure you don't have any trailing slashes on your configuration URLs in Secure Pages.

suffering drupal’s picture

I get this "Your system or network configuration does not allow Drupal to access web pages, resulting in reduced functionality." from the set-up at home too. But I don't get this message at the office and I installed both more or less at the same time in more or less the same way (of course doing EXACTLY the same things on two different computers with Drupal is impossible...)
So why in one should I need to make adaptions and in another I don't???

Anyway, even with this message, everything seems to run ok (cron, updates, whatever...).
So why do I get this message in the first place?

I started with Drupal in 2007 and then my life got stuck...

rares’s picture

see solution by cyberswat

vacho’s picture

The problem is the software platform being used and not in drupal
In my case I use Windows 7, an drupal 6.17 Appserv 2.5.10

SOLUTION I:
Go to: c:\Windows\System32\drivers\etc\

modify the "hosts" file

1. It should be this line not in comments:
127.0.0.1 localhost

2. Comments must be on the next line or eliminate
#:: 1 localhost

SOLUTION II:
I think another option is instead of using the route
http://localhost/drupal/ use http://127.0.01/drupal/

ttomaz’s picture

Solution II worked well for me. Big thanks!

Dig1’s picture

Brilliant, thanks Vacho for your help on this.

I upgraded from Vista to Windows 7. I installed the Apache 2.2.16, PHP 5.2.14 and MySQL 5.1.50.

I downloaded Drupal 7 alpha 6 and got the login page working but it crashed and burned when I tried to log in complaining with a single line saying "The requested URL /domain/reference/actions was not found on this server"!

I then reverted to installing Drupal 6.19 and this time I got a lot further and so I ran the Status report...it explained that everything passed except my http request status...which failed. This was very helpful and so I did a search and found this thread.

Your SOLUTION I modify the "hosts" file:
1. It should be this line not in comments:
127.0.0.1 localhost
2. Comments must be on the next line or eliminate
#:: 1 localhost

has worked perfectly for me and now both versions of Drupal are working (6 does seem a bit quicker than 7 but the latter looks easier for authors to contribute to)

(FYI when editing the hosts file in Win7 you need to open the editor with rightclicking and using administrator access)

Thanks Vacho I can smile again now :)

canogueira’s picture

Thank's.
The trick is the your second point
"2. Comments must be on the next line or eliminate
#:: 1 localhost"

In my case "windows 7 32 xampp" i deleted the line.

minhphuc’s picture

Worked for me! Thanks very much!

VortexCentrum’s picture

I found that changing the config.php file worked without having to modify php.ini.

At line 106,

/**
* Base URL (optional).
*
* If you are experiencing issues with different site domains,
* uncomment the Base URL statement below (remove the leading hash sign)
* and fill in the absolute URL to your Drupal installation.
*
* You might also want to force users to use a given domain.
* See the .htaccess file for more information.
*
* Examples:
* $base_url = 'http://www.example.com';
* $base_url = 'http://www.example.com:8888';
* $base_url = 'http://www.example.com/drupal';
* $base_url = 'https://www.example.com:8888/drupal';
*
* It is not allowed to have a trailing slash; Drupal will add it
* for you.
*/
$base_url = 'http://www.[domain].[tld]/[subdirectory]'; // NO trailing slash!

This last line is 125. I changed this to the absolute URL of the subdirectory in which the installation is made.

I also changed the cookie domain (line 169) to the correct TLD but I don't think this is anything to do with it.

Incidentally, I also un-hashed lines 185 and 187. Not only did that not fix the problem, the site locked me out until I restored a previous version of the file.

Warning gone!

zedxprt’s picture

I am facing the same problem, and that is the reason i am not able to test on RSS feeds, coz' the aggregator not seems to work perfectly.

Please help

leszek.hanusz’s picture

My problem was that the base_url variable in settings.php was beginning with https://

Reverting it to http:// solved the problem

Mohamed Faramawi’s picture

I had my system32/drivers/etc/host looks like this
# 127.0.0.1 localhost
# ::1 localhost

changing it to be

127.0.0.1 localhost
# ::1 localhost

Fixed the problem and sped up the website dramatically.

SergFromSD’s picture

Updating the host file on Vista fixed the issue for me, the only difference is that since I use the machine name instead of localhost I needed to add the following line:

127.0.0.1 mymachinename

lisungroup002’s picture

have the same problem. I tried contacting my webhost, but they need more details regarding php requirements and modules that are being affected by this error. hope it can help me

romeo1981’s picture

set C:\Windows\System32\drivers\etc\hosts

127.0.0.1 localhost

it is OK

I am windows 7 64Bits

tonybaqain’s picture

Actually put the domain itself as 127.0.0.1 in etc/hosts files and will fix the problem, drupal checks its domain first for verifying the HTTP requests capabilities.

MathDoodler’s picture

Just adding to this problem. If you are hosting your self and using Linux(Fedora etc) and you are getting this message, you might want to check SELinux. For instance, you might need to set httpd_can_network_connect, which allows httpd(apache) modules and script to connect to any tcp port. This is one cause for the error on Linux that is using SELinux. To clear the error up, open a terminal as su/root and type the command below.

setsebool -P httpd_can_network_connect 1

LichP’s picture

Another possibility for anyone running drupal inside a VM on their local machine is if you're forwarding port 80 on the VM to a different port on your host computer (e.g. port 8080). This works fine for browsing your site on your host VM, but causes issues with Drupal when it attempts to access itself via port 8080 urls within the VM. The simplest fix in this case is to change your Apache configuration so that the Drupal vhost listens on both port 80 and port 8080. That way, Drupal will then be able to find itself with port 8080 urls and your VM NAT still works as it did before.

To enable port 8080 in addition to port 80 you'll need to make sure you have additional NameVirtualHost and Listen directives in your main Apache config (on Debian / Ubuntu, these directives live in /etc/apache2/ports.conf):

NameVirtualHost *:80
Listen 80
NameVirtualHost *:8080
Listen 8080

Don't remove your existing port 80 directives, unless you really don't want Apache to listen to on the standard port 80 anymore.

Then, to enable port 8080 on your Drupal vhost, edit you vhost config file and update the VirtualHost directive:

<VirtualHost *:80 *:8080>

Reload Apache, and (hopefully) problem solved.

valiant_falstaff’s picture

LichP, thanks for posting this, but I’m having trouble interpreting your instructions: when you say “edit your vhost config file and update the VirtualHost directive,” where exactly is the “vhost config file” in Ubuntu and what is it named?

technivant’s picture

If none of these other solutions work, ensure that your DNS server is actually running, e.g. "named".

mohankiran’s picture

I built an application using drupal7 and now I want to separate the app server (for database access, dynamic processing of PHP scripts) from Apache web service. Is it possible? In CakePHP like frameworks it is possible by modifying the app server configuration, I am new to drupal. Can any one help me? it is similar to 'Reverse proxy'. I am expecting the solution soon, please.

april26’s picture

I was very worried when this happened to me - it turned out that one of my DNS servers was down. I was able to access the site (from the one DNS that was working), but because the second one failed there were all kinds of strange intermittent errors. It has to do with a private nameserver, and it seems it was down for at least a week without really being noticed. Perhaps other people has the same issue.

There are 10 kinds of people in the world, those who understand binary and those who don't!
InterComm South Africa (www.intercomm.co.za)

rodrigoaguilera’s picture

This message is also given when you are running drupal from the php built-in server (php 5.4+) because it can only handle one request and the front page it's not available while you are executing another script.

RumpledElf’s picture

I have this on all my dev sites. Sure enough, adding an entry of 127.0.0.1 to mydevsite.localnet makes the error go away.

danielmm’s picture

Tenia un problema en un sevidor ubuntu 12.04, recien instalado Drupal 7.26, error referenciado aqui.
Modifico el /etc/hosts , y solucionado.

Gracias.

SocialNicheGuru’s picture

I setup a guest environment using virtualbox on my mac host.
I am using aegir to deploy my sites.
I setup a site with url my-local-site.com
I had to add an entry to my guest /etc/hosts file for the guest IP address of my-local-site.com
Then I was able to successfully ping my-local-site.com
Consequently httprl began to work.

http://SocialNicheGuru.com
Delivering inSITE(TM), we empower you to deliver the right product and the right message to the right NICHE at the right time across all product, marketing, and sales channels.

patrickkearney’s picture

I ended up having to figure part of it out on my own and combine other things I found :
(my issue was falsely detecting that it couldn't get out)
Run Cron manually
drush cc all
drush vget drupal_http_request_fails
(if the previous command shows it set to true:)
drush vset drupal_http_request_fails false

And my errors were gone :)