I've just installed Drupal 7, but I'm getting errors in the status report page:

Notice: Undefined variable: errno in drupal_http_request() (line 829 of /home/tixilite/public_html/includes/common.inc).
Notice: Undefined variable: errstr in drupal_http_request() (line 830 of /home/tixilite/public_html/includes/common.inc).

Comments

I recently updated my own website, a hodgepodge of html and php files, to Drupal 7. I started this project using Drupal 6 when 3 days later, they released Drupal 7. Tried the Drupal 6 to Drupal 7 migration on that work but it did not go well.

But 3 days of figuring out how to make something work in Drupal (or any program for that matter) works out to about 3 hours of work future work when you know how it is supposed to be done.

So I started from scratch... a fresh virgin build of Drupal 7; added only the modules and themes required; and then start adding content; avoiding all the mistakes that had been learned from the last 3 days. Hey - what can go wrong?

On my resume, This falls under the rubric of experience, a euphemism for "all the mistakes I made". It will read as "D6 migration - 3 days", "D7 migration- 3 weeks". I digress.

Everything worked great on the dev machine; then I uploaded to the hosting machine, and BAM!.

Notice: Undefined variable: errno in drupal_http_request() (line 829 of /foobar/includes/common.inc).
Notice: Undefined variable: errstr in drupal_http_request() (line 830 of /foobar/includes/common.inc).

This was my answer to the above dilemma. Of course, your mileage may vary (YMMV).

Drupal core fetches data from outside websites. Drupal has its own function - drupal_http_request() to performs this work. There were some subtle changes from D6 to D7.

D7 uses a php function function_exists() to verify that that other php functions exist and are enabled. There is a call to function_exists('ftp_connect') to validate that Drupal ftp transfer will work. I don't know if D6 did this.

In D6 - drupal_http_request() uses the php function fsockopen() to fetch the data (i.e. available updates)

In D7 - drupal_http_request() uses the php function stream_socket_client()

I had to hack into drupal core and then load that up to my production to figure out WTF was going on (@see /includes/common.inc). In retrospect, all I really had to do was look in the Drupal log file and think about it. This would have saved a lot of time. Sigh.

In each include file (D6/D7 common.inc), the php function used in drupal_http_request() is pre-pended with an '@' character which suppresses normal warning messages (correct me if I am wrong here!). Remove this character and you may get warnings from your host provider.

In my particular situation, my host provider had ftp_connect() enabled but had disabled a whole bunch of native php functions which they viewed as security risks. Here is partial information from my phpinfo(). You can view this on your own hosting provider (perhaps) with the D7 Development module installed.

From my host provider:

PHP Configure Command './configure' '-blah-blah' '--enable-ftp' '--blah-blah'

php/disabled_functions: (are you ready for this?)

passthru,
system,
apache_note,
apache_setenv,
closelog,
debugger_off,
debugger_on,
define_syslog_variables,
openlog,
syslog,
ini_restore,
symlink,
ini_alter,
dl,
socket_accept,
socket_bind,
socket_clear_error,
socket_close,
socket_connect,
socket_create_listen,
socket_create_pair,
socket_create,
socket_get_option,
socket_getpeername,
socket_getsockname,
socket_last_error,
socket_listen,
socket_read,
socket_recv,
socket_recvfrom,
socket_select,
socket_send,
socket_sendto,
socket_set_block,
socket_set_nonblock,
socket_set_option,
socket_shutdown,
socket_strerror,
socket_write,
stream_socket_client,
stream_sock

So, uh, 41 php functions have been disabled by my host provider for security reasons. D7 uses one of these (2nd from last). It used to work D6 but not in D7.

I now have 2 options...

  1. plead with my host provider to exempt stream_socket_client() from their disable list (how about just for me?). "Why?" they will ask. They are good managers; keep everything up to date and pretty secure. I am reluctant to change providers. I will say to them "because it's in Drupal 7 core" and they will think about it. (This is long term wishful thinking).
  2. Write a patch so it works like D6 and then Available updates (admin/report/updates) should work for me. This has the advantage of immediate gratification, but ther are also immediate and long term annoying factors, like writing a patch and then maintaining it. phhht.

So I ask the questions - Is stream_socket_client() way better than fsockopen() ? Or is my provider becoming a Homeland Security parody, allowing everything but nothing in, depending on some security hole list that grows larger with time?.

Awaiting enlightenment from all who will share...

I'm awaiting a response from my provider about the php functions. It seems to me that your conclusion is correct (I'm no php expert).

Thanks for the thorough response.

My host provider removed the filter - bless their hearts. It may have helped when D7 was mentioned. I use a shared server, so I'm assuming that the function stream_socket_client() works for all clients on that same server.

Of course, I could be wrong. ;-)