Redirect loop due to conflicting settings

Thanks for this! I was running into the same issue.

This is plaguing me too. Sometimes it happens to the client but I can't replicate it even if I impersonate them.

Has anyone come up with a solution? We have over 40 sites now and will have over 100 by the end of the year and I am implementing this module on all of them.

Having this issue too. This really needs attention.

This happens to me if I first insert the wrong password in the login block, after which action the url gets a "?destination=node" appended to it. It seems like at this point the rules for anonymous role still take precedence over the rule that redirects all authenticated users to the https version even after the login is successful.

Probably there should be a more definite separation between applying role based rules as opposite to path based rules. For example if I want to redirect to https all authenticated traffic, then the only path I may need to add is user* for anonymous users who need to login.

Have you $base_url in your settings.php set? I had a similar problem with a redirect loop from https to http pages and could these (hopefully) solve with uncomment this line.

I just had this occur this morning, quite suddenly. Truncating the cache tables solved it.

All pages were stuck on a redirect loop, i.t. https://example.com, http://example.com, https://example.com/user, etc.

Need to figure out the underlying cause so that I can get it resolved for the client.

I've disabled the option to revert to HTTP when no matches are found. It solves the problem temporarily, but when a cached page expires, that page goes into a new infinite redirect loop until it's generated for an authenticated user. I can't make sense of that.

I just had this same problem and was able to resolve it by commenting out my $baseURL line in settings.php

Hope this helps.

I believe this happens when secure pages caches the redirect for a URL. Most often this is the login page:

For example:
GET http://www.example.com/user

Secure pages responds with a 302 redirect to:
https://www.example.com/user

That redirect is cached in the Drupal page cache if caching is enabled on the site. The cache key is (correctly) http://www.example.com/user

Now, if you set $base_url in your settings.php file with an http protocol - then when checking for page cache results Drupal will always look for http cached pages even if the request came from HTTPS, securepages hooks have yet to fire at this point and update the global $base_url variable.

This is fixed by taking $base_url out of your settings php as mentioned by #9 above but this is a bad idea because there is a security exploit which can make your site vulnerable if you do this. Also, command line tools like drush like to be told what the base_url is and removing this can break some of their functionality.

Instead, work out the protocol before setting $base_url in settings.php. The method to do this depnds on your hosting setup. A standard LAMP stack generally supplies a $_SERVER['HTTPS'] variable you can check so the following would work ...

    $base_protocol = empty($_SERVER['HTTPS']) || strtolower($_SERVER['HTTPS']) != 'on' ? 'http' : 'https';
    $base_url = $base_protocol . '://www.example.com';

I do not know if there is anything securepages can do about this - I am not aware of a hook which fires before page cache is retrieved. This should probably be fixed in the core function drupal_settings_initialize().

I ran into this issue due to a mismatch between the $base_url and the secure base URL.

Thanks, @ceng!!! I also ran into the issue of redirects caused by caching. Making the settings.php change you suggested fixed it.

I have the same issue but I'm not sure I understand #9 and #10.

Does the setting.php must be like this :

$base_protocol = empty($_SERVER['HTTPS']) || strtolower($_SERVER['HTTPS']) != 'on' ? 'http' : 'https';
$base_url = $base_protocol . '://www.example.com';
$base_url = 'http://www.shellac-altern.org';

#9 says don't use a $base_url in your settings.php and #10 has a code snippet you can use instead.

Assuming the URL of your site is http://www.shellac-altern.org (insecure) and https://www.shellac-altern.org (secure) the snippet in #10 for you would be:

$base_protocol = empty($_SERVER['HTTPS']) || strtolower($_SERVER['HTTPS']) != 'on' ? 'http' : 'https';
$base_url = $base_protocol . '://www.shellac-altern.org';

Don't have $base_url declared again in your code, just the code above should be sufficient. Note this was written for an apache & PHP system, other web servers may require different parameters.

This redirect loop problem is really giving me an headache.

Should we only set $conf['https'] = TRUE; when the page being asked for is HTTPS?

This thing just does not work for anonymous users.

After over a week now I finally realize that this was happening because I enabled page caching for anonymous users.

A quick note to say thanks for the solution presented in #10. I was experiencing redirect loops when attempting to use secure pages to protect payment forms and admin pages. It toggles https on/off correctly now.

Setting this to "Needs review" as a Documentation issue; if a $base_url is set with a http scheme (e.g. in settings.php) it's likely to cause redirect loops with page cache enabled as quite early on in the bootstrap drupal_settings_initialize sets the $base_root global using the scheme from the configured $base_url, and drupal_page_set_cache uses that $base_root to determine the cid to use for cache_page.

This means that if securepages issues a redirect from http to https and the 302 gets stored in the page cache (which is what's supposed to happen), subsequent requests which come in over https are treated as if they came in over plain http, and the page cache will respond with the redirect again... and again... and again.

There's probably not a lot securepages can do about this other than document that if you set a $base_url you should add some conditional logic to vary the scheme based on that used for the incoming request (like the example in #10).

Can anyone confirm if #10 works for sites hosted on Acquia Cloud with reverse proxy?

I can confirm that the solution in the #10 comment works! thanks @ceng!

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks