I have seen references to similar problems in other issues, such as http://drupal.org/node/160696 and on the Ubercart forums (Ubercart depends on Secure Pages for controlling which pages are handled by https). I am posting what I've found in a new issue because I'm not sure if I have encountered the same or a different issue as some of the others.

For me endless redirects occurred whenever I enabled Secure Pages in admin/build/modules. It happened without regard to clean URLs, caching or any of the other possible causes that have been discussed in other posts. It also happened in any version of Secure Pages I tried, from 5.x-1.3 to 5.x-1.x-dev. I have previously used Secure Pages on other servers without difficulties.

I finally traced the issue down to the $_SERVER['HTTPS'] PHP global variable referred to on line 262 (of the dev version anyway) in this function:

/**
 * Check if the current page is SSL
 */
function securepages_is_secure() {
  return (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? TRUE : FALSE;
}

You can see that Secure Pages relies on this global variable to determine whether or not the current page is https. Unfortunately it turns out that there is no standard for the $_SERVER variables and not all servers implement 'HTTPS'. (Per: http://www.php.net/manual/en/reserved.variables.server.php) On the server where I encountered this issue the https information is in $_SERVER['HTTP_HTTPS'] instead. I changed the reference on line 262 accordingly and now everything works fine.

For other users if you are having this infinte redirects problem I suggest checking the $_SERVER globals on your server from a https page to determine which one indicates the https status. I have no idea how many PHP variations are out there in the world, so I have not provided a patch. Unless someone comes up with a more elegant solution you will have to patch the module yourself to use the correct variable on your server.

For gordon - As it stands I think the condition on line 262 is always false when 'HTTPS' is not set, resulting in the infinte loop when attempting to display a page that should be https. Perhaps you can devise a means for this to fail more gracefully, or maybe there needs to be a server specific configuration step or maybe an install readme. Since I was able to find a solution, my particular situation is not critical (anymore), but I'm posting this as critical because I know how important this module is to many people. Thanks.

Comments

gordon’s picture

gordon commented
Status: Active » Postponed (maintainer needs more info)

Can you please let me know what web server and OS you are running. As well as the versions.

Thanks.

drupal-at-imediasee’s picture

drupal-at-imediasee commented
Status: Postponed (maintainer needs more info) » Active

OS is: CentOS 5.2
Kernel is: 2.6.18-53.1.21.el5PAE
$_SERVER['SERVER_SOFTWARE'] says: Apache/2.2.3 (Unix) DAV/2 PHP/5.2.6 mod_fastcgi/2.4.6

gordon’s picture

gordon commented
Status: Active » Postponed (maintainer needs more info)

Which version of PHP?

Also I can't find any documentation about why it would be HTTP_HTTPS instead of the documented HTTPS.

This is very strange.

thinkbig’s picture

thinkbig commented
Version: 5.x-1.x-dev » 5.x-1.6

I'm running into the same issue but am using the 1.6 version, not the dev like Steve.
In that version, I believe that the relevant lines are 24-39:

 $page_match = securepages_match($path);

  if ($_POST) {
    // If something has been posted to here then ignore the rules.
  }
  elseif ($page_match && !$_SERVER['HTTPS']) {
    securepages_goto(TRUE);
  }
  elseif ($page_match === 0 && $_SERVER['HTTPS'] && variable_get('securepages_switch', FALSE)) {
    securepages_goto(FALSE);
  }

  // Correct the base_url so that everything comes from https.
  if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') {
    $base_url = str_replace('http://', 'https://', $base_url);
  }

When I change all instances of $_SERVER['HTTPS'] to $_SERVER['HTTP_HTTPS'] I stop receiving the error but Drupal no longer switches to https mode automatically, I have to call it manually.

So I'm guessing this means that http_https is not the appropriate variable for my server. How do I determine which is the appropriate variable to substitute? And is this even the correct place to be substituting it?

I also tried installing the dev version and changing to HTTP_HTTPS but ran into the same problem, secure pages are no longer automatically called.

drupal-at-imediasee’s picture

drupal-at-imediasee commented
Version: 5.x-1.6 » 5.x-1.x-dev
Status: Postponed (maintainer needs more info) » Active

As above PHP is 5.2.6, freshly built on Jul 30.

drupal-at-imediasee’s picture

drupal-at-imediasee commented

@thinkbig, one way to easily access the PHP $_SERVER information from inside Drupal is to create a page with the PHP Code input format with this body:

<?php 
echo '<pre>';
print_r($_SERVER);
echo '</pre>';
?>

You will have to access this page via https to see the https related variable(s).

thinkbig’s picture

thinkbig commented

Thanks Steve. I created a PHP page and when viewed in https mode, here's what it returned. What am I looking for here?

Array
(
    [PATH] => /usr/local/bin:/usr/bin:/bin
    [REDIRECT_STATUS] => 200
    [UNIQUE_ID] => utSY3kgv4BEAAFNaQ0cAAAAw
    [HTTPS] => on
    [DATABASE_SERVER] => ************.com
    [SITE_ROOT] => /home/47127
    [SITE_CGIROOT] => /home/47127/cgi-bin
    [SITE_HTMLROOT] => /home/47127/domains/************.com/html
    [HTTP_PHPCONF] => 1587839028
    [HTTP_HOST] => www.************.com:443
    [HTTP_USER_AGENT] => Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5
    [HTTP_ACCEPT_ENCODING] => gzip,deflate
    [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [HTTP_KEEP_ALIVE] => 300
    [HTTP_CONNECTION] => keep-alive
    [HTTP_COOKIE] => SESSa7ad305b7c1e2ddbc3aba2946cd2d58d=b72e4b4a7058c57321f73de65c613a97; SESS71a5014beaae4a154ea35c8bf9336eac=dab8df16c5b306e8495835d29cb1b730
    [HTTP_X_FORWARDED_FOR] => ************
    [SERVER_SIGNATURE] => 
Apache/2.0.54 Server at www.************.com Port 443


    [SERVER_SOFTWARE] => Apache/2.0.54
    [SERVER_NAME] => www.************.com
    [SERVER_ADDR] => ************
    [SERVER_PORT] => 443
    [REMOTE_ADDR] => ************
    [DOCUMENT_ROOT] => /home/47127/domains/************/html
    [SERVER_ADMIN] => webmaster@************
    [SCRIPT_FILENAME] => /home/47127/domains/************/html/info.php
    [REMOTE_PORT] => 57218
    [REDIRECT_URL] => /info.php
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => 
    [REQUEST_URI] => /info.php
    [SCRIPT_NAME] => /info.php
    [ORIG_SCRIPT_FILENAME] => /etc/apache2/gs-bin/php5
    [ORIG_PATH_INFO] => /info.php
    [ORIG_PATH_TRANSLATED] => /home/47127/domains/************/html/info.php
    [ORIG_SCRIPT_NAME] => /gs-bin/php5
    [PHP_SELF] => /info.php
    [REQUEST_TIME] => 1218042974
    [argv] => Array
        (
        )

    [argc] => 0
)
drupal-at-imediasee’s picture

drupal-at-imediasee commented

@thinkbig, since you have the normal

[HTTPS] => on

your issue is not the same as mine.

drupal-at-imediasee’s picture

drupal-at-imediasee commented

Gordon, Upon further research I now think the non-standard HTTP_HTTPS was probably a local screwup when the PHP or Apache on this particular server was last built. Unless you get confirmation that this is happening to other people you can probably mark this as Won't Fix or By Design. Thanks for your help, Steve.

thinkbig’s picture

thinkbig commented

Steve, to get the info to display I had to turn remove SecurePages. When I reinstall it and try to go to the cart I get a Redirect Loop on all Drupal https pages so although it may not be the same configuration, I'm getting the same problem in the end (see attached). Any ideas of who might know how to fix this or if I should be looking in a different thread?

gordon’s picture

gordon commented

Your version should work.

gordon’s picture

gordon commented
Status: Active » Closed (works as designed)

As recommended

davea’s picture

davea commented

What page(s) are you trying to secure?

What payment gateway module are you using?

Thanks,
DaveA

drupal-at-imediasee’s picture

drupal-at-imediasee commented

@davea, whom are you asking? me? In my case the pages and payment gateway involved are irrelevant.
For me the root cause did turn out to be a mis-configured Apache. The manifestation of the problem was the infinite redirects when Secure Pages was turned on, because the expected $_SERVER['HTTP'] wasn't there. Since $_SERVER['HTTP'] is a defacto standard it's completely reasonable for Gordon to assume it will be there on any https page. So this isn't a bug for Secure Pages after all, hence the by design designation. But this post might be useful to anyone encountering an infinite redirect with Secure Pages because it shows that Secure Pages might not be the actual cause of the problem, and gives one possible place to look.
@thinkbig, you need to look elsewhere. We have proven that although your problem manifests the same its root cause is unrelated to mine.
That should pretty much do it for this thread. Thanks everyone. And apologies to Gordon for the false alarm.