Global Redirect not working on a nginx server

I can confirm this is also a bug in the latest 7.x-1.x-dev version as well.

Forgot to make this a bug report

Ok, I've found what the issue is (at least in my case). It looks like globalredirect_request_path() is using $_SERVER['REQUEST_URI'] which does not exist in my case. So I added the following fastcgi_param to my conf file for my domain:

fastcgi_param REQUEST_URI $query_string;

Everything works now.

Scratch that. It works for global redirect, but causes a ton of other issues.

Early testing on modifying the line in #3 to read:

fastcgi_param REQUEST_URI $request_uri;

Is looking good.

Coder review of globalredirect.module suggests using request_uri()
http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/reques...

Line 375: the use of REQUEST_URI is prone to XSS exploits and does not work on IIS; use request_uri() instead
if (isset($_SERVER['REQUEST_URI'])) {

Line 381: the use of REQUEST_URI is prone to XSS exploits and does not work on IIS; use request_uri() instead
$request_path = strtok($_SERVER['REQUEST_URI'], '?');

No patch to review here.

Here's a patch based on the recommendations in #6.

Forgot to change the status

Hmm, let's try this again...

Committed - was looking at changing this earlier but decided not to for some reason. Then saw your patch, changed it and ran the tests to be sure that the green above was true... Seems to be fine! :-)

This has gone into the 7.x branch now.

The patch in #11 still doesn't cut it for me on nginx. The reason for this being the setup of fastcgi:

fastcgi_param REQUEST_URI $request_uri;

This results in this code snippet:

    if (isset($_REQUEST['q'])) {
      $path = $_REQUEST['q'];
    }

to produce a completely wrong $path variable. I can fix this by removing the above mentioned fast_cgi_param, but as it's a common way of setting this up, we should fix the module, not the server. 'q' is always in $_GET anyway...
Patch in attach.

The more I think about this, the less I understand this globalredirect_request_path() function. Why use the $_GET['q'] or $_REQUEST['q'] at all? I really don't get that, as doing it this way:

/**
 * globalredirect_request_path() is borrowed from request_uri(), but it only ltrim's..
 */
function globalredirect_request_path() {
  if (request_uri()) {
    $request_path = strtok(request_uri(), '?');
    $base_path_len = drupal_strlen(rtrim(dirname($_SERVER['SCRIPT_NAME']), '\/'));
    // Unescape and strip $base_path prefix, leaving q without a leading slash.
    $path = drupal_substr(urldecode($request_path), $base_path_len + 1);
  }
  else {
    // This is the front page.
    $path = '';
  }

  // Under certain conditions Apache's RewriteRule directive prepends the value
  // assigned to $_GET['q'] with a slash. Moreover we can always have a trailing
  // slash in place, hence we need to normalize $_GET['q'].
  $path = ltrim($path, '/');

  return $path;
}

Will cover all cases: clean, non clean etc... Can anyone explain? What use case am I missing then?

someone will fix this?

Is there any news to resolving this issue?

This patch works for us. Can you please commit it.

Looks good to me. thanks for the follow-up patch.

Committed to 7.x-1.x-dev

Sorry, but needed to revert this. On a clean D7 install, with only Global Redirect enabled and this patch - the site ended in an infinite loop on the frontpage. This needs more love before we can commit this.