Nginx SSL Redirect Loop

This config doesn't exist in the vanilla Aegir. It look like you are running BOA? Then you should read the how-to: http://drupalcode.org/project/barracuda.git/blob/HEAD:/docs/SSL.txt and generally search the issue queue before posting duplicate issues.

A hint: redirect loop can be caused by the standard global SSL proxy provided by BOA. BOA is not designed to support Aegir SSL feature (at least not yet). Read the SSL how-to.

Ah, I assumed you are using BOA because you have submitted this issue first in the BOA old queue on GitHub. Sounds like a bug then!

Just to confirm, which Aegir version are you using? I assume 1.x, because in the 2.x we don't have nginx_simple_include.conf any longer.

This should be fixed in 1.x and 2.x since we have the same config also in the extended (default) Nginx config in 2.x

However, I'm not sure if this is what causes the problem, so this needs further investigation.

so yeah, @hadsie, let's try to reproduce this in 2.x shall we? :)

What is your browser identity? These two locations are designed to prevent known bots and crawlers from indexing never ending sub-pages, like generated by calendars and exposed views. These locations don't cause any loop, just permanent redirect to $args-free URL, if bot/crawler is discovered:

###
### Send all not cached requests to drupal with clean URLs support.
###
location @drupal {
  error_page 418 = @nobots;
  if ($args) {
    return 418;
  }
  rewrite ^/(.*)$  /index.php?q=$1 last;
}

###
### Send all known bots to $args free URLs.
###
location @nobots {
  if ($is_bot) {
    rewrite ^ $scheme://$host$uri? permanent;
  }
  rewrite ^/(.*)$  /index.php?q=$1 last;
}

It also honors URL scheme, as you can see.

I would suggest to test this more, looking at HTTP headers with curl -I url to find what exactly happens and where. It could be also somewhere in the code, module used, its configuration etc. At least, I don't see any reason in the Nginx config to cause redirect loop.

Also, take a look at how we suggest to do it in BOA, in the local.settings.php directly: http://drupalcode.org/project/barracuda.git/blob/HEAD:/aegir/conf/overri...

And if you are using a module for this, I hope you have applied required patches to Drupal core, as we do it in our enhanced D7 core: https://omega8.cc/how-to-add-custom-platform-properly-140 and https://github.com/omega8cc/7x/tree/7.23.1

can we get a diff with the regular config files?

@hadsie

I would take a look at the vhost sections/rewrites instead of locations/rules in the included config.

The SSL feature and corresponding logic responsible for SSL enabled vhost generation has been modified during SSL refactoring, and I never tested it after these changes. It is still possible it never worked under some never tested conditions, and that those modifications had no impact, but I just want to point out that we (at Omega8.cc and more generally, in BOA) never experienced issues like this, but we also never used Aegir built-in SSL feature, just SSL proxy and otherwise standard includes, so maybe there is a culprit hidden we haven't discovered yet.

Please confirm whether this is still an issue in Aegir 2.0+.

The 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing
this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open,
or better yet, create a new issue referencing this one.

I've found that this happens in Aegir 3.5 and 3.6 as well.

Create an aegir site with SSL enabled (not required).
Don't redirect to a specific domain (www or otherwise - may still break with redir, but trying to keep things simple)
Enable securepages with the following options:

"Switch back to http pages when there are no matches" checked.
Set your non-secure and secure base URLs:
http://DOMAIN.COM
https://DOMAIN.COM

Set your secure URLs with either option "secure all except" or "secure only...".

Now load a page and click a link that would take you to the "other side" (secure if on an insecure page, insecure if on a secure page).
You should get a redirect loop. Hard-refresh should then load properly.

What's happening is that nginx is caching the 302 redirect and serving it repeatedly.

I found a solution!

In /var/aegir/config/includes/nginx_vhost_common.conf:
In the "location = /index.php" block, change this:

fastcgi_cache_key "$is_bot$device$host$request_method$key_uri$cache_uid$http_x_forwarded_proto$sent_http_x_local_proto$cookie_respimg";

to

fastcgi_cache_key "$scheme$is_bot$device$host$request_method$key_uri$cache_uid$http_x_forwarded_proto$sent_http_x_local_proto$cookie_respimg";

Adding the $scheme to the fastcgi_cache_key prevents the 302 from being cached for secure and re-served on insecure or vice-versa.

Edit: I apologize - upon further review of the original post - mine is an entirely different problem... But it is still a redirect loop related to nginx and securepages.

@millenniumtree -- Please open new issue. Thanks.

I have opened new issue #2768869: Nginx fastcgi_cache_valid TTL logic is incorrect