i moved my site to a nginx server and i got the 310 (net::ERR_TOO_MANY_REDIRECTS) error, i tried to install the Nginx Fast Config module but the problem is still. Any idea to fix the problem?

Files: 
CommentFileSizeAuthor
#14 global-redirect-nginx-1317142-14.patch807 bytesmalc0mn
Test request sent.
[ View ]
#11 global-redirect-nginx-1317142-11.patch939 bytesDrakeTaylor
PASSED: [[SimpleTest]]: [MySQL] 192 pass(es).
[ View ]
#8 global-redirect-nginx-1317142-8.patch940 bytesDrakeTaylor
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in sites/default/modules/globalredirect/globalredirect.module.
[ View ]

Comments

Version:6.x-1.2» 7.x-1.x-dev
Assigned:sagitta» Unassigned
Status:Needs work» Active

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

Category:support» bug

Forgot to make this a bug report

Status:Active» Needs review

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.

Status:Needs review» Needs work

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

Status:Needs work» Needs review

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'], '?');

Status:Needs review» Active

No patch to review here.

StatusFileSize
new940 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in sites/default/modules/globalredirect/globalredirect.module.
[ View ]

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

Status:Active» Needs review

Forgot to change the status

Status:Needs review» Needs work

The last submitted patch, global-redirect-nginx-1317142-8.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new939 bytes
PASSED: [[SimpleTest]]: [MySQL] 192 pass(es).
[ View ]

Hmm, let's try this again...

Status:Needs review» Fixed

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.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Needs review
StatusFileSize
new807 bytes
Test request sent.
[ View ]

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:

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

<?php
/**
* 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?