Create first account fails, returns to welcome page

OK. Now, I'm getting really confused. It's beginning to look like maybe a browser problem, but this same browser/os/machine has done several other drupal installations. Here's the details. I've begun putting lots of debugging statements at the head of various functions. These are usually of the form: print "<p>function_name: start.</p>\n"; I put these into the following functions:

• drupal_validate_form()
• user_register_submit()

I also swapped out db_query for db_queryd in user_save(). From my browser (firefox 1.5.0.7, Ubuntu Linux), I got no output of debug statements. I was simply redirected to the front page every time.

Tonight, I got a copy of the cookies and postdata that firefox was sending to the server and used the POST command present in most Linux systems to try this from the keyboard, with the actual urls and values obfuscated, here's what happened:

echo 'edit%5Bname%5D=admin&edit%5Bmail%5D=admin@example.com&edit%5Bform_id%5D=user_register&op=Create+new+account' | POST -se -H 'Cookie: __utmz=256468839.115332256.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); __utma=288957839.776485167.1153486690.1186555690.1154681380.1; PHPSESSID=e6018138e2af669f3c577ef735feb811' http://example.com/newsite/index.php?q=user/register>out.txt

The output (in out.txt) was

200 OK Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0
Connection: close
Date: Mon, 02 Oct 2006 03:09:16 GMT
Pragma: no-cache
Server: Netscape-Enterprise/6.0
Content-Type: text/html; charset=utf-8
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Mon, 02 Oct 2006 03:09:14 GMT
Client-Date: Mon, 02 Oct 2006 03:10:29 GMT
Client-Peer: 130.184.5.11:80
Client-Response-Num: 1
X-Powered-By: PHP/5.1.4

<p>drupal_validate_form: start.</p>
<p>user_register_submit: start.</p><p>user_register_submit: got name=admin, mail=admin@example.com</p><p>user_register_submit: at save.</p><p>query: INSERT INTO users (name, mail, pass, init, status, created, uid) VALUES ('admin', 'admin@example.com', 'eda330f6421dfe802a9d202bf4c7d693', 'admin@example.com', 1, 1159758554, 2)<br />error:</p>

I'm clearly getting my debug requests back. So, I checked the database. This time, my account was created. Since I copied my cookie from the browser, if I hit the site from the browser, I find that I'm logged in, uid=1. So, I tried to change my password. I was returned to the front page. From the database, that didn't appear to work as the md5 hash didn't change. To be sure, I tried to enable the aggregator module from admin/modules. When I clicked "save configuration," I was again returned to the home page. Revisiting admin/modules showed that aggregator had not been enabled (the box was still unchecked).

My question now is, what changed? Why would this work under lwp-request POST, but not from firefox? Looking at packet captures of both firefox's and lwp's request, there are differences, but mostly in the Accept- headers. The only thing I can see that Might make a difference is the Content-Length header. Firefox makes it 104, the exactly length of the postdata, while lwp-request makes the value 105. I don't think this is making a difference.

Any suggestions where I should look next?

It didn't even occur to me to mention this in my original post. My web host is running php in cgi mode.

I've found a few mentions of this:

• http://drupal.org/node/11861
• http://drupal.org/node/20663
• and in particular http://drupal.org/node/20663#comment-52230

It seems that this is a known problem, but the solution itself isn't widely known. The first item I'll be trying is a change to php.ini:

cgi.fix_pathinfo=1 #default is 0

Also, I wrote a quick test, which essentially amounts to print_r($_SERVER); to which I receive the wonderful "no input file specified" error. I'm not sure if the two are related, So I'll also be playing with php's doc_root setting.

Anyone else seeing anything like this?

Well, this may not be the right way to do this, and I think I'll start a new thread to ask questions, but I've come up with a work-around. It seems that I'm getting a $_SERVER['REQUEST_URI'] value set, but one that is not right. I don't know if it's the same CGI issue or not, but $_SERVER['argv'] and $_SERVER['QUERY_STRING'] are both right. In other words a call to info.php (containing a call to phpinfo() among other things) gets me this:

Request: http://example.com/info.php?foo=bar

Respose:

$_SERVER['REQUEST_URI'] => info.php
$_SEVER['argv'] => Array
        (
            [0] => foo=bar
        )
$_SERVER['QUERY_STRING'] => foo=bar

So, I simply went into includes/bootstrap.inc and modified the request_uri() function to ignore $_SERVER['REQUEST_URI'], resulting in the following code:

function request_uri() {

  #if (isset($_SERVER['REQUEST_URI'])) {
  #  $uri = $_SERVER['REQUEST_URI'];
  #}
  #else {
    if (isset($_SERVER['argv'])) {
      print "<p>request_uri: using argv</p>\n";
      $uri = $_SERVER['PHP_SELF'] .'?'. $_SERVER['argv'][0];
    }
    else {
      print "<p>request_uri: using query string</p>\n";
      $uri = $_SERVER['PHP_SELF'] .'?'. $_SERVER['QUERY_STRING'];
    }
  #}

I don't know if this is the best solution. I'm getting in touch with my webmaster to find out how things are configured. But until then, this may do the trick.

Well, it appears that I've successfully navigated through and fixed the problem.

See Fix for broken request_uri on some systems for my description and fix.