Ok, please note I am a very novice coder and I am not completely sure that this is even a bug. I don't think "Global Redirect" is actually causing the problem, but I think it could do some conditional checking to see if a host is running PHP as CGI. I am having the same issue I was having before in 4.7 with redirects being sent as "301 OK." ( http://drupal.org/node/114857 ) I have been searching around to see if it's even important (say for Google and other spiders) if a "301 OK" header instead of "301 Moved Permanently" is even a problem but have not found anything indicating one way or another.
(Please note, on my test box at home I have absolutely no problems. The mod works perfectly. But my host runs PHP as CGI [PHP-CGI/0.1b] and that is when I see this "301 OK" instead of "301 Moved Permanently" during redirects. (I have been using the Live HTTP Headers addon for FireFox to do my testing ( http://livehttpheaders.mozdev.org/ ))
In 4.7.x-1.x-dev I was able to change
header("HTTP/1.1 301 Moved Permanently");
to
header("Status: 301 Moved Permanently");
This sent the proper 301 headers for 4.7 for my install.
In the current dev version though I can't see where I can make this change. I added a few lines though and the headers seem to be sent properly on my CGI install.
All I did was add header("Status: 301 Moved Permanently") above the drupal_goto() calls and it seemed to fix it for me, though I am sure there would be a better way to do this. That's about where my knowledge ends. :|
<?php
//$Id: globalredirect.module,v 1.1.2.4.2.2 2007/02/06 01:09:28 njt1982 Exp $
/**
* Implementation of hook_help().
*/
function globalredirect_help($section) {
switch ($section) {
case 'admin/modules#description':
return t('This module will do a 301 redirect for all nodes which have an alias but are not using that alias.');
}
}
/**
* Implementation of hook_init().
*/
function globalredirect_init() {
if(isset($_REQUEST['q']) && function_exists('drupal_get_path_alias') && !isset($_REQUEST['destination'])) {
//Get the Query String (minus the 'q'). If none set, set to NULL
if (($query_string = drupal_query_string_encode($_GET, array('q'))) == '') {
$query_string = NULL;
}
//Lets do a check to compare the current url to the site's frontpage.
// If matches, redirect to the frontpage (eg, http://www.mysite.com/)
if(drupal_is_front_page()) {
header("Status: 301 Moved Permanently");
drupal_goto('', $query_string, NULL, 301);
}
//Check the current url (eg, node/123) for an alias... If set, redirect to it
$alias = drupal_get_path_alias($_REQUEST['q']);
if ($alias != $_REQUEST['q']) {
header("Status: 301 Moved Permanently");
drupal_goto($alias, $query_string, NULL, 301);
}
//Check if the current url ends in a slash (eg, node/123/)
if(substr($_REQUEST['q'], -1) == "/") {
//Ok - it does. Seeing as it didn't have an exact match WITH the slash in the above test, lets try without...
$alias = drupal_get_path_alias(substr($_REQUEST['q'], 0, -1));
if ($alias != $_REQUEST['q']) {
//We matched an alias for the current URL with no slash - redirect to that...
header("Status: 301 Moved Permanently");
drupal_goto($alias, $query_string, NULL, 301);
}
}
}
}
Here is my setup also if it helps:
Modules Installed:
Google Analytics 5.x-1.x-dev
Google Sitemap 5.x-1.0
Node style 5.x-1.1
Meta tags 5.x-1.0
Pathauto 5.x-1.0 (disabled)
Front Page 5.x-1.6 (disabled)
Server Setup:
Server API: CGI
Apache/1.3.37 (Unix) mod_fastcgi/2.4.2 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a PHP-CGI/0.1b
Comments
Comment #1
nicholasthompsonWhy are you using the 4.7-dev version of GR when you list 5.x modules below your modded code?
Also - this issue has been previously mentioned, however you've brought a new issue to the table - the CGI vs Apache Module option. I only ever run PHP as an Apache module - I've never tried to run it as CGI. Can anyone else with similar specs try to confirm this?
Comment #2
citricguy commentedI was referencing how I was able to adjust this in the 4.7 dev version of GR in Drupal 4.7. I use the 5.x dev version in Drupal 5.1 now. Sorry about not clarifying that, haha, I tend to go on nonsensical tangents. :) I had the same issue in both versions.
I was looking around at a couple of over projects that may have run into the same issue, and it looks like vBulletin and vBseo for instance have ways to check for CGI installs before outputting 4xx or 3xx pages.
I'm think this topic belongs elsewhere though. Seems like it would be a drupal thing rather than per-mod.
Comment #3
nicholasthompsonI agree - this is starting to sound like a core patch. Nicely found, diagnosed and researched though!
Comment #4
hass commentedthis is more a PHP bug... i seen this on IIS 5.1 and 6.0 with ISAPI dll, too.
put this code inside a "redirect.php" outside drupal directory. if you see the same issues this is for sure a PHP bug... i'm sure it is.
Comment #5
furmans commentedI wonder if this is a problem with the default Apache rules in Drupal. I've *finally* fixed my problems with GlobalRedirect in nginx by fixing the Clean URL rule in my nginx configuration file.
Try the following URLs on your site and see if GlobalRedirect works in each case (assuming that Clean URLs are enabled, and GlobalRedirect is on):
1) Without leading "/" after "q=":
http://yoursite.com/index.php?q=node/12) With leading "/" after "q=":
http://yoursite.com/index.php?q=/node/1I found that GlobalRedirect worked in case (1) above, without the leading "/" after the "q=". Case (2) did not work for me.
Looking at the Apache rules, I see something that may be a problem. I don't have an Apache setup anymore, but I remember poring over the .htaccess file for some other reasons.
Drupal .htaccess file:
I think it might need to read as follows to remove the leading / from the $1 argument in the last line:
I had to do something similar in nginx in order to get GlobalRedirect to work:
If this is the case, perhaps the .htaccess file in the Drupal distribution needs fixing?
Comment #6
hass commentedNope, this rewrite rules are correct. Maybe you have used wrong URLs in your nodes. Never use leading or trailing slashes in URL aliases.
Comment #7
nicholasthompsonMarking as fixed as there has been no response for almost a year.
Comment #8
batbug2 commentedif nobody minds i'd like to confirm that furmans' solution for nginx+phpfastcgi works and now GR works 100%
Comment #9
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.