Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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?
Comment | File | Size | Author |
---|---|---|---|
#14 | global-redirect-nginx-1317142-14.patch | 807 bytes | malc0mn |
#11 | global-redirect-nginx-1317142-11.patch | 939 bytes | DrakeTaylor |
#8 | global-redirect-nginx-1317142-8.patch | 940 bytes | DrakeTaylor |
Comments
Comment #1
DrakeTaylor CreditAttribution: DrakeTaylor commentedI can confirm this is also a bug in the latest 7.x-1.x-dev version as well.
Comment #2
DrakeTaylor CreditAttribution: DrakeTaylor commentedForgot to make this a bug report
Comment #3
DrakeTaylor CreditAttribution: DrakeTaylor commentedOk, 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.
Comment #4
DrakeTaylor CreditAttribution: DrakeTaylor commentedScratch that. It works for global redirect, but causes a ton of other issues.
Comment #5
DrakeTaylor CreditAttribution: DrakeTaylor commentedEarly testing on modifying the line in #3 to read:
fastcgi_param REQUEST_URI $request_uri;
Is looking good.
Comment #6
paulrooney CreditAttribution: paulrooney commentedCoder 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'], '?');
Comment #7
Dave ReidNo patch to review here.
Comment #8
DrakeTaylor CreditAttribution: DrakeTaylor commentedHere's a patch based on the recommendations in #6.
Comment #9
DrakeTaylor CreditAttribution: DrakeTaylor commentedForgot to change the status
Comment #11
DrakeTaylor CreditAttribution: DrakeTaylor commentedHmm, let's try this again...
Comment #12
nicholasThompsonCommitted - 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.
Comment #14
malc0mn CreditAttribution: malc0mn commentedThe 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:
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.
Comment #15
malc0mn CreditAttribution: malc0mn commentedThe 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:Will cover all cases: clean, non clean etc... Can anyone explain? What use case am I missing then?
Comment #16
eule CreditAttribution: eule commentedsomeone will fix this?
Comment #17
dillix CreditAttribution: dillix commentedIs there any news to resolving this issue?
Comment #19
Jaypan CreditAttribution: Jaypan at Jaypan commentedThis patch works for us. Can you please commit it.
Comment #20
BarisW CreditAttribution: BarisW at LimoenGroen commentedLooks good to me. thanks for the follow-up patch.
Comment #22
BarisW CreditAttribution: BarisW at LimoenGroen commentedCommitted to 7.x-1.x-dev
Comment #24
BarisW CreditAttribution: BarisW at LimoenGroen commentedSorry, 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.