i installed the DEV version on 5.1 and this one creates an endless redirection loop with the following logic. so i tried to comment this 3 lines and the site was ok.

if(drupal_is_front_page()) {
  drupal_goto('', $query_string, NULL, 301);
}
CommentFileSizeAuthor
#31 frontpage1.patch2.08 KBhass
#25 bugfix2.patch2.88 KBhass
#23 bugfix1.patch2.85 KBhass

Comments

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

What is your frontpage set to?

hass’s picture

hass commented

"node", what is the standard install setting. i never changed anything here.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented
Assigned: Unassigned » nicholasthompson

Interesting - I'll look into this. It didn't cause a problem for me when I set it to node on my dev server. Thanks for pointing this out.

Do you have any other modules enabled which could interact with GR to cause this (so I can install them too to test).

hass’s picture

hass commented

i have this installed:

globalredirect
gotwo
localizer
nodewords
node_clone
node_style
panels
pathfilter
path_redirect
robotstxt
site_map

i'm able to remove them step by step and see if it changes anything... aside i'm using Drupal 5.1

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Hmmm... I'll take a look - only the path redirect ones could possibly cause an issue, but i cant imagine why.

Thanks for bringing this up.

hass’s picture

hass commented

But one thing i can say for sure is - path_redirect doesn't have any config vor "/" or "node" - 1000% sure.

I filed some time ago another bug where i'm reported that Google is DoS'ing (http://drupal.org/node/124513) me. I think this is absolutely related to this bug. It looks to me (not tested) that the function drupal_is_front_page() works (sometimes) different in 4.7.x and 5.x. I assume in 5.x it says every time TRUE for the path "/" and "node" what results in a loop - in 4.7.x only if "node"... but if google comes it say TRUE on "/", too, what makes google looping... (330.000 frontpage redirect requests in one night on a site with only ~50 nodes)

So my bug http://drupal.org/node/113327 looks like a duplicate now, but the documented info should be correct, nevertheless drupal_is_front_page() seems not be a solution here.

brashquido’s picture

brashquido commented

I'm also getting this with 4.7.x-1.x-dev. I have my frontpage set to "node" and firefox gives me this error after some time;

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

* This problem can sometimes be caused by disabling or refusing to accept
cookies.

My installed modules apart from the required ones are;

adsense
adsense injector
akismet
authorship
bbcode
captcha
comment
contact
db_maintainence
db_tuning
download_count
flatforum
forum
forward
graphstat
gsitemap
image
image_gallery
links
links_related
links_weblinks
menu
nodevote
nodewords
page
path
pathauto
poll
privatemsg
profile
search
service_links
simplenews
sitemap
smtp
spam
statistics
story
subscriptions
tagadelic
taxonomy_breadcrumb
taxonomy_image
throttle
tinymce
trackback
tracker
troll
upload
votingapi

Wow, that is a lot of modules....

I'm also having some issues with Googlebot, but as I only just enabled gsitemap and submitted it to Google a few weeks ago I'm not sure if it is related.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Okey dokey - i'll look into the frontpage issue. Seems GR related!

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

I just had a few minutes to check on a 5.1 test site (running PHP as an Apache module V5.1.6, Apache V2.2.2 and MySQL 5.0.27) using the dev release of GR. I tried a few combinations to break it but all seemed to work fine. I tried:
* setting the frontpage to 'node' and promoting two nodes with aliases to the frontpage. Confirmed as working.
* setting the frontpage to 'node/1'. Confirmed as working (eg, going to / showed the right page. Going to node/1 and the node's alias redirected to / and worked fine).
* Just accessed a node by its system path and i was redirected to the alias.

I had no redirecting issues at all using the '5.x-1.x-dev' version released on 6th Feb.

If I get a chance latest, I will do a complete reinstall of Drupal 5.1 with that GR 5.x dev version (i know its the same as its the dev site I committed it from).

I cant see any reason why this wont work.

How is PHP installed on your server (ie Apache module or as CGI?)

hass’s picture

hass commented

IIS6 as CGI
Apache2 (prefork) as php4_module

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

IIS6... This could be interesting... All I need now is a Windows Web Server to test the module on...

I know PHP as CGI has an open issue with this module in that the redirection headers are incorrectly sent.

brashquido’s picture

brashquido commented

I'm using IIS 6 with PHP 4.4.4 in FastCGI mode

hass’s picture

hass commented

But google is looping on my Apache2 with PHP4 box... IIS is only on my DEV box...

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

So is the same problem occurring on both server's?

I'm not looking to shift the blame off to the server - I'm interested to know the configuration as I cannot replicate this issue with my setup (all my server's are Redhat-based with Apache 2 and PHP as a module).

Thanks,
Nick

hass’s picture

hass commented

ops, ony fault... my is IIS 5.1 (WinXP)

hass’s picture

hass commented

Someone working on this KILLER bug?

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Unfortunately, I cannot replicate it and so therefore I cannot debug it...

Are you using the dev version of GR or the "official release"?

hass’s picture

hass commented

An altered DEV version... with the frontpage redirection removed.

hass’s picture

hass commented

as i know the 4.7.x-1.1 version i'm using is the final - but the frontpage redirection is deleted, too.

vacilando’s picture

vacilando commented

Same problem here. A hint for the developers that may point to a - hopefully speedy - solution:

http://quidne.vacilando.org - works in IE, has this error in FF (also loads 'node'). It worked fine for FF as well (perhaps some installed module broke it).
http://www.quidne.vacilando.org - works fine in both browsers!!
http://www.nezbud.org - works fine in both IE and FF!

I work on XP.

Please help and let us know asap, this is really bad.

Cheers,

Tomas

vacilando’s picture

vacilando commented

Well - in my case, I have just found that when I switch off module Persistent Login v5.x-1.2 - then this error disappears from FireFox! Seems like the others don't use that module. Must be pointing to a more serious issue somewhere.

Btw I am on Drupal 5.1.

Tomas

hass’s picture

hass commented

i'm not useing "Persistent Login". never heard about.

hass’s picture

hass commented
Status: Active » Needs review
StatusFileSize
new bugfix1.patch2.85 KB

this one should fix this bug.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Hass - thanks for the patch... Although most of the lines are minor changes. The most important change is changing:

if(drupal_is_front_page()) {

to

if ($_REQUEST['q'] == variable_get('site_frontpage', 'node')) {

Thing is - drupal_is_front_page() basically does the same thing except it also resolves any frontpage url's from alias to system (which is something I've never considered - someone having an alias for a frontpage system URL... That would make 3 routes to the same page!).

The other changes in the patch seem to just be moving a return value from a variable to directly into an if statement (and vice versa). Thing is - You changes:

    $alias = drupal_get_path_alias($_REQUEST['q']);
    if ($alias != $_REQUEST['q']) {

to

    // Check the current url (eg, node/123) for an alias. If set, redirect to it.
    if ($_REQUEST['q'] != drupal_get_path_alias($_REQUEST['q'])) {

but because there is now no $alias variable, the next line:

drupal_goto($alias, $query_string, NULL, 301);

fails because $alias isn't set...

Thoughts?

hass’s picture

hass commented
StatusFileSize
new bugfix2.patch2.88 KB

the http://api.drupal.org/api/5/function/drupal_get_normal_path inside drupal_is_front_page() looks like the main problem for the endless loop... how is it possible to have more then one unique frontpage?

you are right. i killed the $alias variable... lets turn this back... the rest is only "make the code looking nicer".

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

how is it possible to have more then one unique frontpage?

Ok - say you create a view... my_view/arg1/arg2
Now you create an alias... my_frontpage_url -> my_view/arg1/arg2
Now you configure your system to use the system url for the frontpage (my_view/arg1/arg2).

Ok, using your method (just looking at the system variable 'site_frontpage'), you're just comparing the url entered to the configured frontpage. Someone could link to the my_frontpage_url alias and youre method wont pick this up, but it will still show dupe content...

However I believe this falls into the category of protecting the user from their own stupidity which isn't the purpose of this module.

My concern is why drupal_get_normal_path is causing these loops...

hass’s picture

hass commented

sorry, i don't understand this:

Now you create an alias... my_frontpage_url -> my_view/arg1/arg2
Now you configure your system to use the system url for the frontpage (my_view/arg1/arg2).

Frontpage URL is http://www.example.com/ - isn't it? If i install drupal in a subdirectory, i get http://www.example.com/test/ - ok, but in this case my frontpage becomes automatically http://www.example.com/test/ and site_frontpage stay as "node" - nothing else isn't it?

Only thing we need to prevent is http://www.example.com/node is indexed, while this is a duplicate of http://www.example.com/. If /node is called we do a 301 redirect to http://www.example.com/ and all is ok. if i change my frontpage path (never done this yet) i get a new frontpage like my_view/arg1/arg2. if this url will be accessed we do 301 to http://www.example.com/. so again all problems solved... i don't know if /node is accessible in such a case... maybe we should place a manual redirect for http://www.example.com/node if the fontpage path is not "node"...

i know in past you have had a line $frontpage = variable_get('site_frontpage', '/') inside the code - but this must end in an endless loop if "site_frontpage" variable is not defined. I will try to spend some time on the drupal_get_normal_path() - but it looks like the same problem... you get a "/" back and find a request url like "/" what ends in looping from url "/" to "/" - not 100% sure, but the only idea how an endless loop is possible.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Say, In your example of the frontpage being "node" - say you give that an alias, for example, "frontpage_node_alias". Now in the settings, whichever "path" you tell Drupal to use as the frontpage, there will be another one that "your" method wouldn't cover. By using the get normal path method, you only need to work with system paths.

As for the "/" thing - as I understand it, that's not necessary. Your site is http://example.com/ and the "q" is node/123. So to redirect to "root" you just make q empty (effectively) by redirecting to '' (blank), not '/'.

hass’s picture

hass commented

i think i finished some more analysis. This problem have nothing to do with drupal_get_normal_path() - the problem is inside drupal_is_front_page() only!

1. the request to http://example.com/node comes in
2. drupal_is_front_page() is called and give TRUE for the URL http://example.com/node
3. redirect is invoked to http://example.com/
4. drupal_is_front_page() is called and give TRUE for the URL http://example.com/, too
5. an endless loop begins from http://example.com/ to http://example.com/ while drupal_is_front_page() gives evertime TRUE

if we check out what drupal_is_front_page() does i saw $_GET['q'] returns node for requests to http://example.com/ and drupal_get_normal_path(variable_get('site_frontpage', 'node') gives node, too.

so inside function drupal_is_front_page() the line: return $_GET['q'] == drupal_get_normal_path(variable_get('site_frontpage', 'node')); what ends with return node == node; and therefor TRUE.

Something i currently don't know is - $_GET['q'] and $_REQUEST['q'] gives different results. $_GET['q'] is 'node' and $_REQUEST['q'] is '' for the frontpage. i hope this is all correct... but please don't ask me why this is not reproduceable every time. Maybe the $_GET['q'] is sometimes different.

hass’s picture

hass commented

Here i found why $_GET['q'] and $_REQUEST['q'] is different:

[bootstrap.inc]
/**
 * Seventh bootstrap phase: set $_GET['q'] to Drupal path of request.
 */
define('DRUPAL_BOOTSTRAP_PATH', 6);

looks like we need to stay at $_REQUEST['q']... or there will be another way to distinguish between original url and drupal url. Aside it will be a good idea to get this module into core and solve this issues in this way and not with such hacks :-).

hass’s picture

hass commented
StatusFileSize
new frontpage1.patch2.08 KB

here is a rerolled patch against 5.x-1.1

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Thanks for the patch - I've committed a slightly difference approach to the fix in 5.x-dev, can you take a look and let me know your thoughts?

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/globalredirec...

Basically, it does a "!epmty($_REQUEST['q'])" check before doing the drupal_is_front_page() check. This SHOULD stop the looping on the frontpage.

That was a nice bit of debugging you did there! Interesting why this doesn't seem to happen on my dev box or production servers (all Linux based with PHP4/5 as a module (ie, not CGI) and running Apache 2.x).

hass’s picture

hass commented
Status: Needs review » Fixed

thx, seems working. i hope this works every time now...

dries’s picture

dries commented
Status: Fixed » Closed (fixed)