HTTP request status fails

[dkingofpa]

When doing a stock install of vagrant-drupal, the resulting drupal site's status result page states that the HTTP request status failed.

Some background on the issue

• http://drupal.org/node/588186
• http://drupal.org/node/245990

Steps to reproduce

1. Follow Basic Usage steps in readme.
2. Log in to site.
3. Go to http://localhost:4567/admin/reports/status

Cause of the issue

The system_check_http_request function in modules/system/system.module makes a call to the drupal_http_request function in includes/common.inc that results in a connection refused. drupal_http_request tries to open a socket via php's stream_socket_client. Printing out the socket, options, and result shows that drupal is trying to connect to the port we use in the web browser on the host.

socket:  tcp://localhost:4567

options:  Array
(
    [max_redirects] => 0
    [headers] => Array
        (
            [Host] => localhost:4567
        )
    [method] => GET
    [data] => 
    [timeout] => 30
    [context] => 
)

result:  stdClass Object
(
    [code] => -111
    [error] => Connection refused
)

Potential workarounds

1. Ignore the error. It's not actually breaking anything.
2. Bypass the error message so Drupal makes the requests anyway. http://drupal.org/node/245990#comment-1312270
   • Manually add that conf variable to settings.php or code it into the non-prod recipes?
3. Some coding to determine if we are using port-forwarding in the Vagrantfile. If yes, apply some magic using opscode's iptables or firewall cookbooks.

[pearcec]

I took a look at this. There are there cookbooks available to us:

• firewall -- abstracted cookbook to deal with firewalls. This is the future.
• iptables -- this is the past and they are warning it will be deprecated
• uwf -- A wrapper on top of iptables

Adding the REDIRECT is easy enough to add on the command line but it requires using table nat. None of the cookbooks support adding a rule to the nat table. The closest is the iptables cookbook. It runs the script rebuild-iptables. If we populate the file /etc/iptables.snat with the REDIRECT it will work. It is not ideal, but for development purposes should be sufficient for now.

[pearcec]

I have what I believe to be a working solution. But it is rough. Rather than much up the code base I am going to pull this into a fork and then you can evaluate if you like the implementation.

[dkingofpa]

Is this something for which we can create a branch rather than forking? A la git-flow? We shouldn't have to fork every time we do development on our own project. I wanted to start using git-flow as we maintain and added to the project. As good a time and project as any to learn how git-flow feels.

On Jan 16, 2012, at 2:19 PM, Christian Pearce wrote:

I have what I believe to be a working solution. But it is rough. Rather than much up the code base I am going to pull this into a fork and then you can evaluate if you like the implementation.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

xforty technologies
David King
http://xforty.com
888-231-9331 x1160

[pearcec]

I fixed it.

xforty/chef-drupal@a710946