for kindred souls: understanding "HTTP Server Request Fails" (particularly in drupal6 default!!!)

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: http://xmlrpcflash.mattism.com/proxy_info.php

In other words, to everyone having this problem. Try uploading the script found here: http://xmlrpcflash.mattism.com/proxy_info.php 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

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

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!

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)!

Footnotes:
(*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.

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,

Izzy

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

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...

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

First, i've made the common.inc hack described in http://drupal.org/node/245990.
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 (http://xmlrpcflash.mattism.com/proxy_info.php) 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 site.com 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!

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.

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!

Thanks!

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

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.

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 http://mydomain.net, because the server refuses the loopback connection, while connecting to http://127.0.0.1 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...

David

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

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??

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 http://wiki.dreamhost.com/index.php/Allow_url_fopen

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

There is a really easy fix for this, that is based on the article already posted here: http://collectiveidentity.net/node/13

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
http://xentek.net

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 "hawaiianislands.com"
You have a server that has multiple vhosts on it.
The servername is called "bigkahuna.hawaiianislands.com"
You've got several sub-domains running as vhosts on "bigkahuna" - i.e. "boards.hawaiianislands.com", "shorts.hawaiianislands.com", and "aloha.hawaiianislands.com".

Now, if you decide you want to develop a new drupal site, you'll want to create a new sub-domain and vhost - like "sandbox.hawaiianislands.com" 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 bigkahuna.hawaiianislands.com - but when the HTTP request fired the server would transform bigkahuna.hawaiianislands.com to localhost before making the request...and the Drupal HTTP request system doesn't like that.

Goodluck!

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 http://collectiveidentity.net/node/13

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.

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 http://drupal.org/project/http_request_fail_reset for reseting drupal_http_request_fails flag.

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.

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() ?)

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: http://bugs.php.net/bug.php?id=44335&edit=2

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.
/etc/hosts
nnn.nnn.nnn.nnn example.com www.example.com ftp.example.com ...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.

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 master.drupal.org blocked. Everything went fine after unblocking.

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.

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