so for those of you who may have been through this, beating your heads against the wall wondering what that "HTTP Request error is on your admin and update screens, here's some insight (i've been digging into this for hours, and so this explanation may only relate to typical web hosts - including my own, mediatemple, an otherwise great host)

remote file inclusion through php is the numero uno security issue for most hosting providers, and so in an effort to make this not possible they have all been shutting down the ability to put out requests via php for http calls (including out to and so on) a result, this means you can't A) use the update status module, B) use OpenID and C) use aggregator module

but what's confounding is that you might set up your site and it might all work fine for a few days or weeks until a hosting admin sees the activity and flips the switch - then you'll see errors (that's what happened to me)...

in this case, don't worry, drupal is still just fine, as are all of the mods BUT you can not enable update status or aggregator or openID (or others that put out http requests through php) because they'll return errors and do note that you will now forever see an alert on your admin interface prompting you to enable update status even though you know that you can't...bummer.

at least this is the case with me and mediatemple and many other hosting providers taking the same lead...

the implications are awful: open source is great, but the same openness has led hackers to a wealth of penetration strategy which has led hosts to shut down loopholes - in turn this cripples some app functionality and may, for example, hinder the overall growth of things like OpenID in open source apps (many built of php and installed in one-click install environments for example)

this does NOT explain everything, but may offer insights for those of you wondering what happened or what you did wrong - before you slam drupal forums with bug reports (as i and others have already done), understand that it may in fact be your host, NOT drupal!!!

as for a fix, some hosting providers may allow for you to edit the php.ini file to allow for this to all work (php fopen configuration in php.ini, or fsock open or whatever it's called) but not all will - or they'll warn you against it because it will expose (possibly) whatever other sites are on that server or in that cluster/grid etc...

that's about it. just wanted to share the summary of what i figured out today after it was all good and these errors started appearing...


k2xl’s picture

Thanks for the post. I've been pulling my hair out too. But I'm still not sure it's my webhost. I uploaded a PHP proxy script to get around crossdomain.xml issues with Adobe Flash last week when I developed an RSS feeder for an application; I had no problems there and that php script used http (I think) to download the rss feed. This is the php proxy:

In other words, to everyone having this problem. Try uploading the script found here: and try loading a rss feed and see if it works right. I don't know if drupal uses the same functions, but it could gather some insight.

I use MediaTemple as well (on dedicated-virtual).

Anyway, maybe I'm wrong. I have my php.ini file open right now

just tell me The Chosen Variable and the value that will lead us all to freedom

zilla’s picture

so i had a long talk with a very bright guy at MT last night, and here the options available include: leave it disabled and just ignore the warnign to 'enable update status' (have a request in to core drupal to allow user to disable the associated warning witha core module) OR edit php.ini to allow the request - and they say this is fine and allowed at MT but will expose your entire container on the grid (an issue for me because i've got some wordpress installs and it's just not as secure as drupal imho, but whatever)...

however, i explained to the MT guy that when they upgrade drupal6 in their one-click installs options this year, then every single customer is going to be calling - 100 percent of them - with an identical error (because they'll all try to enable the module and so on)...he completely agree and has moved the issue up to the development team to examine further.

one idea i suggested was a configuration for drupal on MT in which the calls go to and are then run through html (somehow) and brought back and forth through some other proxy (perhaps even use some variation of a feedburner account to execute this for example, for feeds) - and they could actually mirror the drupal CVS as well - but that requires real work, and also requires that they feel they have enough of a drupal user base...

so at any rate, per your other way around with adobe, that will probably be shut off as soon as they find it, so don't be alarmed - in which case you may want to talk to them about fsockopen ideas and what they'll allow when you edit that php.ini file if you choose to do so...the specific guy i talked to who has dealt first hand with the http request closeouts that took place just this past month (in january actually) is 'milton' - he's really great, very sharp...

k2xl’s picture

Can someone tell me what setting to change on the php.ini ??

zilla’s picture

here's what they say, "You can enable 'allow_url_fopen' by editing your php.ini . The process is very straightforward; it is as simple as including the following line to your own php.ini file at /home/####/etc/php.ini (Replace the #### with your site number) If you are just starting to use a custom php.ini file you may need to also change the memory_limit value as well.

allow_url_fopen = On

article is at:

k2xl’s picture

Mine is already enabled... Still doesn't work.

Shiny’s picture

but will expose your entire container on the grid (an issue for me because i've got some wordpress installs and it's just not as secure as drupal imho, but whatever)...

you can enable it on a per virtual host basis -- php_admin_flag in apache. Then you can leave this off for wordpress.


wavesailor’s picture

Do we have a work around for the non-techie people?

zilla’s picture

updatestatus in the core...that's about it for now. there are some other threads about how to configure your site to get around the proxy server - just search drupal for "http request" or ["http request (fails OR error OR server)"] on google

z3cka’s picture

Try this module:

*It says not to use on a "live site" ... so i'm assuming that you turn it on, clear cache, run cron, let it fix your problem and then turn it off.


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

duh. shoulda realized that - but strange, huh? i guess offline is really 'shut down http request'

other related discussion here...

LeonardoMerino’s picture

Offline Status? Where is that?

zilla’s picture

when you click admin you'll see a site maintenance option - it lets you take your site 'offline' to visitors so that only the admin can hop around (e.g. for when you're updating modules or doing things on a busy site - you don't want people logged in!)

Janne’s picture

I love it when things are so much easier than it seems! :)

KatongKid’s picture

er, sorry, but how do you "remove" offline status? You set status as either offline or online...

My host's allow_url_fopen = on but I'm still getting the "HTTP request status Fails" error.


atuyo60’s picture

ya how do you remove the status? you can only set it on or off and my site is online but I still get the error.

according to it seems that what you are doing maybe just clearing the variable that has the error set and I got my problem solved following this article, however I do not know why this is happening... it seems like a drupal bug and not a problem with our hosts since I had drupal 5 working fine

Janne’s picture

Not sure if this is what you're talking about, but anyways:

The "offline status" reffered to in this thread would be the "maintenance mode" that takes your site offline for everyone but administrators. This disables the possibility for Drupal to contact your site to check for available updates for your themes or modules, since Drupal (for obvious reasons) should not have that type of access to any site.

You can fint the site maintenance function in the "settings" menu in the admin-section of your site.

loloyd’s picture

I custom built a theme and based it on Bluemarine. My method was to copy the entire Bluemarine directory and pasted it on /sites/all/themes/. I then renamed the directory name to Greenmarine_over_black and then edited its css files.

All appeared to work well until I visited /admin/reports/status - I got this dreaded "HTTP Server Request = Failed". It took me a while figuring out what had happened and some significant amount of backtracking the steps I made. I remembered that I also edited /modules/system/system-menus.css and /modules/system/system.css to fit my theme's needs(*1). So I replaced that with the default ones and then rechecked my /admin/reports/status. It still showed me "HTTP Server Request = Failed". I also tried the entire site reinstallation and then replace files including settings.php approach but that still failed. I even cleaned out my cache and uninstalled several core modules to no avail.

A few hours of raised hair spread over days later, I noticed a few weird warnings at the top of my Drupal pages - probably caused by my playing around with the files and database. It all led me to edit the info file of Greenmarine_over_black theme assigning it a unique and filename-matching name and $Id value. Thank God, THAT SOLVED MY PROBLEM. I can even go back to modifying core files again (which I know is against the Drupal way, but that's sorely the fastest way I know how)!

(*1) I now added my edits to /modules/system/system-menus.css and /modules/system/system.css to the end of my custom theme's style.css instead to mitigate other diff problems. This will be much more update resilient in the future.

izmeez’s picture

I am also having the HTTP Request Access failure and it did seem to just start on it's own.

It may well have started when I was copying a core theme to the sites/all/themes to modify it. Since reading the comments in this thread I went back to the core theme and deleted the copy altogether. I don't think I have to do anything else for it to be removed. It didn't solve my problem.

I upgraded to Drupal v6.2 and everything else seems fine including resolution of the 403/404 problem. But, the HTTP Request access failure is still there.

I have tried to create the xml_proxy.php file and installed it on my site, and tried following the instructions a number of times but it is not working. I know nothing about this level but this method sounds like it might be the best if it worked.

Any help would be appreciated. Thanks,


izmeez’s picture

I have submitted the HTTP request status fails as an issue.

I am wondering if the problem is related to taking the site offline and then back online and some item that is altered is not being reset.


gumdrop’s picture

Some intermittent issue when the site is offline, that's what I am seeing.

mmachina’s picture

you must take your site online to get the php.ini file to work... if you are offline, aggregator updates do not work.

izmeez’s picture

I have since discovered and posted in the issues that I have determined that through .htaccess redirect to an hhtps:// SSL site this problem was occurring. I removed those lines and it worked and then when I readded the lines it worked in stops and starts at first and is now working fine.

Izzy’s picture

this error started occuring after i had the aggregator feed turned on and later switched it of...
turning the aggregator module back on, fixed the problem...

yang_yi_cn’s picture

For my case, on the status report page, I just run the Drupal update check manually and it fix the problem!

13mhz’s picture

First, i've made the hack described in
then, i have run check manually and i have received versions of updates. After downloading updated modules and updating database, i did the xml_proxy.php hack ( and change one of my rss feeds in the script's manner - it went good, but only once!
after that all the errors came back, but this time it appeared like this: The feed from seems to be broken, because of error " ".
After turning site offline (maintenance mode) and back online, rss feeds got via xml_proxy.php once good, other time was returning errors, now everything seems to work, but i don't know for how long and i'm pretty confused...
anyway, thanks for your help!

spyjournal’s picture

installed 6.2, enabled aggregator - it worked for 1 day
then this 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.

we then spent a day researching it and trying various things - nothing worked
after coming here we emailed surpass to see if they could turn it back on.
the surpass people were kind enough to write this to us

The drupal aggregator module needs 'allow_url_fopen' to be turned on in the PHP configuration. This is strictly disabled in the server in the interest of overall system security.

Even though this feature allows a program/code to include, open or use a remote file using URL instead of local path, it is a source of large number of security holes in PHP based web applications that may affect the integrity of shared environment.

This will not affect the Drupal at all, but only to the aggregator module. Please ask the developers of the software asking whether there is any other workaround available to use this feature in these restricted environments. You can use curl library and its associated functions as a solution to this issue.

Let us know if you have further queries. Thank you.

We have moved the site to one of our xHost servers instead.

ozchris’s picture

i dunno.

I'm running a test version locally on a xampp installation on my PC. I didn't think that used .htaccess.
I've never used aggregator.

For me it seemed to start after I installed prepopulate and custom_links. As soon as I did that, I started getting a blank screen when I selected Administer. I could create content though, and display the site.
The only way to get back to the Administer screen was to delete the above two modules.

That was when I got the HTTP message.
I ran update.php. I ran Cron manually. I took Maintenance mode offline and online. Still got that message.

Still no answers. No way on earth will I install those modules to my live site until I fix my test environment.

reptilo’s picture

Same problem after 15 days without any problem !
I have installed some modules and themes and then have this message.

ozchris’s picture

I couldnt fix my local test environment.

It wasn't just those two modules - when I tried to add any new modules, I would get the http error.
I have to remove the last added module, to be able to access the Administrator menu.

I bit the bullet and added the two modules to my production environment, and so far so good.

To fix my local test environment, i'm tempted to just backup all the production environment, and start again.

just wanted to clarify that it wasn't those particular modules that caused my problem. But I miss my test environment.

Observer8’s picture

The "allow_url_fopen" parameter was On, but it still doesn't work:

allow_url_fopen = On

But in the list of "disable_functions" was fsockopen:

disable_functions = exec, popen, passthru, system, fsockopen, shell_exec, ...

I remove it from the list, like this:

disable_functions = exec, popen, passthru, system, shell_exec, ...

And all start working fine after that!


P.S. I place edited php.ini file in the Drupal root directory, so it can's harm or affect any other hosting sites.

alasda’s picture

Whatever you try as your solution, run cron from inside drupal before deciding that your fix hasn't worked. Drupal doesn't seem to pick up changes until cron has successfully been run.

David Stosik’s picture

Hello zilla,
Thanks for your post which explains the problem.
I want to add that this problem may be the consequence of other point: my web hosting service allows outside HTTP connections, BUT, loopback connection is refused! That is, my PHP or shell scripts can't connect to, because the server refuses the loopback connection, while connecting to still works...
Thus, I'm not able to use drupal_http_request, which first checks a local URL is accessible, and I can't configure my cron task neither.

My two cents...


neocary’s picture

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 just turned on and fed the feed aggregator and this is what i got..Will this error also effect digg this?
Its a pretty bad error considering the popularity of rss in SEO
A Fix is def needed-if this is a godaddy issue i need to know because rss is vital to seo

izmeez’s picture

Yes it can be very frustrating and hard to identify the specific problem and conditions leading to it.

We had the same problems when we first started using Feed aggregator running on Drupal 6.1 but, fortunately our problem went away and we weren't really sure why as it coincided with adding the google analytics module.

And our problem remained solved as we upgraded to 6.2, 6.3 and now 6.4 although I believe the problem occurred once more recently when we had been making some cron setting changes and we just enabled Poorman's cron once and then disabled it and everything is fine for now.

As you may have found there are several threads in which this problem has been discussed:

Hope this helps some.


neocary’s picture


rennemannt’s picture

I'm running a Windows 2003 server and I was having this problem. Instead of installing a loopback adapter I added an entry in my C:\WINDOWS\system32\drivers\etc\hosts file:

This seemed to have fixed a lot of my problems.

winterheart’s picture

Thank you!
Your suggestion helped me too!
From Siberia with Love!

AxMstrLP’s picture

Though I had a loop-back adapter installed on the host itself, my router blocks loop-back requests. Spoofing myself with the /etc/hosts file worked.

So drupal says "fetch". DNS resolves to my WAN IP address. The requested is made through the WAN IP address and the router blocks it (or, rather, doesn't loop it back).

Setting the entry in the /etc/hosts file will prevent "" from resolving to the WAN IP address and, for the machine with the modified /etc/hosts, it will resolve to the specified location (either loopback or LAN IP).

Note that the problem is with router loopback (not the loopback on the host). That means all machines on my subnet are going to fall victim to this problem. So lets say my router forwards WANIP:80 to This will work for all machines coming from outside my network. Lets say machine tries to hit It will fail. INSIDE my network, every machine should have its /etc/hosts file associate with "". So then when .1.20 tries to hit it will resolve to and no loopback will take place.

madaerodog’s picture

after a lot of thinkering with no luck around media temple panels, I've done the php.ini trick, and made a manually update of the site, and it's all green now

karlcw’s picture

I added the line allow_url etc to my php.ini and now my website runs so much faster when logged in as admin.

Not sure if this was an intended side effect but I can cope with running manual update requests occasionally now that admin doesn't take an age to load pages.

Training in Leicestershire and throughout the East Midlands, UK
Spread Betting Community

NikLP’s picture

See also this re a possible problem with cache :

Maver77’s picture

I have the same issue "HTTP request fails" on one of my sites, so no RSS feeds got updated and no drupal update checks. As I have three sites on the same installation of drupal core - a multisite installation-, the issue is only on one of the sites as the other two are working just fine. Does anyone have ever noticed the same??

JamesOakley’s picture

I've got the same bizarre thing with a multisite installation. The same files, 3 settings files, 3 databases. Only one of those instances has this problem.

Solid VPS providers that I've used and can recommend first-hand:
  Managed VPS Providers  ||  Unmanaged VPS Providers
rosencrantz’s picture

Just heard back from my hosting company, DreamHost, on this one. They suggest using cURL instead of the php.ini change. Anyone know if this is feasible without hacking at the core? Perhaps a module?

their writeup on the topic is at

I see there are some aggregator modules that use cURL, but what about for checking for updates?

xentek’s picture

There is a really easy fix for this, that is based on the article already posted here:

Just add variable_set('drupal_http_request_fails',FALSE); to template.php, visit your homepage, then remove that line from template.php. This will clear the error, and keep you from hacking core.

I'm not saying its not a bug, but this will at least get you past the hung flag, so that http status requests will begin working again. After I did this, every thing worked again.


Eric Marden

NikLP’s picture

Surely if this is a flag or somesuch, then it can also be edited directly in the variable table using the devel.module?

I have suspicions that other things can cause it - my cron stopped working at the same time, and I worked out that it was because I had protected the site using htaccess rules. Removing these worked for enabling cron. I haven't yet tested whether this corrects the aggregator problem but I have a suspicion that it may well do.

Web Design & Development in Nottingham by Kineta Systems

neocary’s picture

This note is for anybody on Godaddy under the freehosting plan who experienced a loss in feeds once they upgraded from 6.2 upward.
I have spent WEEKS on this issue and can say that NOTHING works. Hacking core won't work. the countless suggestions won't work in these nodes won't work

All related posts on what clearly is an existing problem

core hack suggestion & patch (which users report may not work):

Collective Identity in depth discussion and walk thru of core hack

Moving over to Acquia won't work either but they really demonstrate best in class customer service and have actually been a pleasure to work with.

zilla’s picture

unreal. it was working perfectly since i modified the allow_url in php.ini, i mean since this posting went up months ago - but now it's back, just today, some time this afternoon - after a rash of cluster issues at mediatemple...hoping it's temporary, because if can't run the request then my site can't really go far, can it ;) bummer...

i love to waste time:

justin.hopkins’s picture

I've discovered also that if your servername is the same as your hostname you'll have this issue due to conversion to localhost.

For example:
You own a domain ""
You have a server that has multiple vhosts on it.
The servername is called ""
You've got several sub-domains running as vhosts on "bigkahuna" - i.e. "", "", and "".

Now, if you decide you want to develop a new drupal site, you'll want to create a new sub-domain and vhost - like "" on bigkahuna rather than do your developing at the default apache www folder.

If you do put your development site in the default apache folder - it would be available at - but when the HTTP request fired the server would transform to localhost before making the request...and the Drupal HTTP request system doesn't like that.


jabevan’s picture

Do I understand correctly that this is typically a shared host issue and that a dedicated server or VPS either does not/will not have this issue, or can be fixed??

Josh Bevan
Only local images are allowed.

zilla’s picture

my understanding is that in a shared hosting environment, the settings are always 'highest safety' for the group before hte individual user, though some hosting providers (like mine, mediatemple) allow for the user to change this in an 'upper tier' shared environment -
i love to waste time:

DoctorMike’s picture

I have Version 6.8 and triggered the HTTP Server Request Fails by setting up Google Apps / Google Docs to use as the editor for our blog / Story updates in Drupal.

When I activated the Blog.api and then used Google Docs to update a Story, this caused the HTTP Server Request Fail.

Then I could not get it back to normal, until I hacked the code using the information on this page

It worked to fix the error, but the error returns if you post with Google Docs from outside of Drupal.

Then you have to run Cron to fix the error again. Once cron runs all better until you post with the blog api.

I hope this post helps Drupal or another one of you great programmers out there come up with a better way than hacking the core code.

With Google becoming a more major player in online editing, it would be nice if Drupal would play nice with them.

kenorb’s picture

Similar Problem: The feed ... seems to be broken, because of error " The server can't issue HTTP requests".

After added two options in php.ini:

allow_fopen_url = On
allow_url_fopen = On

It worked!
I've used for reseting drupal_http_request_fails flag.

Scott M. Sanders’s picture

This D6 module is very helpful if the issue is intermittent and you have no admin access to edit things on the server.

Deviation’s picture

For what its worth, I ran into this issue after adding an additional IP to my server. Apache wasn't restarted even though the network service was. Verifying the correct host entries and restarting Apache seemed to work for me. It seems like it had issues with the hostname.

borat’s picture

Nothing should ever require either of the following:
allow_fopen_url = On
allow_url_fopen = On

There are other (right) ways to achieve the same functionality (pehaps http_get() ?)

Nick Wilson’s picture

For anyone using Bluehost, they dissallow url_fopen unless you have a dedicated IP (which compared with their regular prices is a complete rip off), BUT.....

Set up a parked domain, (or a subdomain) and set it up in your sites/ directory etc etc then use THAT domain to mirror your main sites module setup and it will go fetch the updates just fine.

not perfect by any means, but its better than spending the extra money on a dedicated IP just for this small bit of functionality..

mbelos’s picture

Hi guys,

If you're getting this error on Vista, check your hosts file (C:/Windows/System32/drivers/etc/hosts). This problem relates to PHP5 on Vista, where the hosts file contains the following line:

::1 localhost

Remove that line, run the following command as an Administrator (ipconfig /flushdns), restart your browser and try again. For more info, check out this link:

beric’s picture

Thanks, THAT worked! ;) ...after many hours searching for a solution! And my Drupal runs a LOT faster after this change. (No, I don't like vista either!)

Shelichrg’s picture

From my reading here: and a few other places the ::1 entry in the hosts file is the ipv6 localhost entry. I know the protocol isn't really used but removing it may have unexpected side effects.

As for the the error; a weird thing happened to me. I added the http:// in front of the localhost in the hosts file and that solved my problem. I was trying to recreate the error, however, even after removing it (http://), flushing the dns, restarting the browser and apache and clearing the browser cache the 'Http request status' error never came back. Well at least not yet.

If anyone else has come across this please let me know if the error comes back.

I'm working on my local machine - Vista, with a new drupal install: version 6.12 using firefox, safari and chrome.

AndrejT’s picture

After reading this I am know nothing. I am on beginning.
My midphase host says:

I apologize but your server is now blocking outbound port 80 which is the port
HTTP requests are made on. This is because of security vulnerabilities
involved with this. Please let us know if there is anything else we can do to
assist you. Thank you.

Best regards,
I have
Drupal 6.12
update status module disabled
allow_url_fopen = On

BUT how can I now know which modules I need to upgrade?
The available updates page outputs this:
Cron ran successfully.
The content access permissions need to be rebuilt. Please visit this page.
Last checked: 2 days 22 hours ago (Check manually)

No information is available about potential new releases for currently installed modules and themes. To check for updates, you may need to run cron or you can check manually. Please note that checking for available updates can take a long time, so please be patient.

If I check manually:

* Unable to fetch any information about available new releases and updates.
* The content access permissions need to be rebuilt. Please visit this page.

Last checked: 2 days 22 hours ago (Check manually)

No information is available about potential new releases for currently installed modules and themes. To check for updates, you may need to run cron or you can check manually. Please note that checking for available updates can take a long time, so please be patient.

Midphase has disabled outbound port 80 because there are known security issues related to leaving this port open. To look for upgrades for Drupal, you will need to go to and check for their posted updates. Drupal is offered through Fantastico, although the only support we offer is the initial installation. Once the code has been installed and modified by the client, it is up to the client to maintain their sites security and keep their version of Drupal up-to-date. Again, if you want to look for Drupal upgrades, you need to go to to see their available updates. Let us know if you have further questions.
Best regards,


NOW it is OK. I report later which module was the reason for this (after disabling some modules the update status check went to OK status).

AndrejT’s picture

I was not able recognise the troublemaking module or the solution, because I have more modules enabled then before and all is OK. Some informations on this forum says that the feed modules are the reason and you must enable/disable them and update status module disable/enable, maybe http request fail module enable and so on, but I can say only now is all OK.

niczoom’s picture


Removing the line '::1 localhost' from my HOSTS file cleared up Drupals 'Status Report' issues.

It also brought back Google's 'show options' link (on the left in results) in Firefox 3, which has not been working for a while (no idea why).

Thanks again, Nic!

Carow’s picture

Thanks for this info; it seems to have worked for me.

I just installed Drupal 6.16 using XAMPP 1.6.7 on Windows Vista Business sp2. This HTTP Request Error popped up on the Status Report immediately following the install. I edited my hosts file at C:/Windows/System32/drivers/etc/hosts by using # to comment out this line as follows:

#::1 localhost

The Status Report is clear now (hooray!).

BTW, in order to edit the hosts file on Vista you will need to go to the Start Menu, All Programs, Accessories, RIGHT CLICK Notepad, then select "Run as administrator". Navigate to the hosts file to open it. You will need to change the filetype from txt to all files to see the hosts file. Thanks to for this info.

sparky888’s picture

Thanks for the change in HOSTS solution. I wasn't able to fetch available updates on my Acquia multisite setup, and this cleared up the problem right away. Thank you!!

EdCazini’s picture

Hi, allow me to pitch in my observations.
Here's my architecture:

  • server hosting - home-brewed using Virtualmin+Webmin, behind a NAT firewall
  • CentOS 5.3, Apache 2.2.3, MySQL 5.0.83, PHP 5.2.9

I already had 4 live virtual domains on this hosting machine; 3 Drupal 6.12 & 1 Moodle. I then created another virtual domain via the Virtualmin+Webmin management, & then ran through Drupal 6.12 installation. All went well until I got to check the status report where I got the error message as in the subject of this thread. Also note that all these virtual domains are configured with dedicated virtual LAN IPs.

Investigating, I noticed that the differences of this new virtual domain against the other 4 are:

  1. hosts file entries exist for the old domains, this one has none
  2. I enabled DNS for it, whereby creating DNS entries all pointing to the dedicated public IP I assigned.

Hence I figured out external client HTTP requests coming to the virtual domain where successful but host machine's own HTTP requests to the new virtual domain resolved to the public IP, a loop out to the public & going back in. This may well be the cause (worth another investigation but fathomless for me for the moment).

What I did to resolve the problem was just to add the virtual LAN IP of this new virtual domain to the machine's hosts file. I think pointing to localhost's loopback IP as rennemannt suggested would work as well.
nnn.nnn.nnn.nnn ...etc...

Well you may wonder why I got you bored with the lengthy details, but I suspect this might just be the case for those commercial virtual hostings out there.

andyan’s picture

I just added one line following the instruction here on the file /etc/hosts on my host server(CentOS 5.x) and it fixed the trouble.

lostchord’s picture

Make sure you apply this for all interfaces on a multi-homed system!

We are born naked, wet, and hungry. Then things get worse.

eelkeboezeman’s picture

I had the same kind of issues on my shared hosting account. After checking all php.ini settings, I contacted the helpdesk. They informed me that there was actually a page in my Control Panel where I had to enable outgoing HTTP requests. When I visited the page it had blocked. Everything went fine after unblocking.

Gemkeepers’s picture

Thank you for that information it is really helped me :)

sgriffin’s picture

HTTP request staus fails can occur when you try to serve off domain content via ssl.
Which has a simple solution of not showing your embedded (youtube, flash content) on your ssl pages.

philberndt’s picture

Hello, i had the same problem on my VPS running Drupal-7.b3, this was resolved when i changed from lighthttpd to apache.

ikeigenwijs’s picture