Redirect loop cause if $_GET['q'] is changed by custom module.

I originally posted this issue at PURL's issue tracker: #877696: PURL doesn't integrate well with all modules

The problem is that globalredirect checks if $_GET['q'] is the same as $_REQUEST['q']. This is a little simplified, as $_GET['q'] is run through various manipulations to get path alias if any, add language prefix etc. The problem is, however, that globalredirect doesn't support any other modules changing $_GET['q']. This is what PURL does.

Idea behind purl is that you can make a url like this: pony/node/30. In this case pony can map to anything like a node, user etc, and purl will let you hook into this, by calling your function of choice, with the info that pony which maps to an id is "active". It changes the $_GET['q'] so that Drupal will return the rest of the url (node/30) which can be rendered in this special context.

The problem is that $_GET['q'] gets changed. As purl acts before globalredirect, globalredirect will currently detect this change and make a redirect make to the original url pony/node/30. PURL will do the same thing, and globalredirect will once again redirect, causing the loop to go on.

This is just one example, but any module that alters $_GET['q'] before globalredirect's hook_init is run, will cause this.

I'm not sure what the best cause of action will be, but this limits the usefulness of global redirect quite a lot. Instead of having special cases like the ones that have been made already, we should try to find a generic solution, to avoid future problems with other modules.