Detect HTTPS requests and set HTTPS server variable so Drupal respects original request scheme.

I'm not in a good position to test this right now, but I did something similar with an external (to Aegir) HTTPS proxy so that Drupal sites know about it. See the example I added to Using a load balancer or reverse proxy.

Not sure about D6, but for D7 I set the $base_url. In D8, I didn't even have to do that. In both cases, I didn't need to explicitly enable HTTPS so maybe it figured this out from the proxy? So you probably just have to set that.

Shouldn't we set this in the vhost templates, rather than in settings.php?

But Drupal still needs to know the proxy IP addresses. Where are you setting those?

It'd be good to remain consistent. We already set that param here, along with lots of other headers.

Both Nginx and Apache provide simple conditional syntax:

• http://httpd.apache.org/docs/2.4/expr.html#examples
• https://www.digitalocean.com/community/questions/conditional-within-an-i...

+1 for setting the var

@ergonlogic, adding it in the apache/nginx templates looks more complex .. and note that with the use of an external SSL termination the ssl variant of these templates is often not used, ss it would have to land in both ssl and non-ssl variants.

The $_SERVER['HTTPS'] belongs in settings.php (PHP level) not in the vhosts (web server level) and is pretty harmless addition as it affects only proxied requests with external HTTPS termination.

Both Jon and helmo are correct that it can't even be done on the vhost level, because vhost is not aware of external HTTPS termination, only aware of local request which is plain HTTP.

Also, the ssl on; Nginx directive is not the same as $_SERVER['HTTPS'] and is already deprecated in newer Nginx releases, plus, even if Nginx offers the if() logic (which should be avoided like plague btw), many/most directives can't be put within if() anyway.

I should also mention that we are using similar logic in the global.inc in BOA to make HTTPS support more predictable for many years already.

For reference, so we don't overlook this later:

https://stackoverflow.com/questions/51703109/nginx-the-ssl-directive-is-...
https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-s...
https://nginx.org/en/docs/http/configuring_https_servers.html

I respectfully disagree. PHP expects $_SERVER to be set by the web server: http://php.net/manual/en/reserved.variables.server.php

No regex or other complex logic should be required in the vhost to accomplish this. Setting a header in response to another header's value is common practice.

While it would have to be set in the non-SSL vhosts selectively, it should be set by default in the SSL ones.

As it stands, we're making changes to how we pass this into each version of Drupal. We'll presumably need to hack this into Drupal 9+ as well.

Since we're doing this in PHP, other apps (such as JS running on hosted sites) won't have access to these modified headers.

Anyway, I'll stand aside. I still disagree with the implementation, but I won't block it.

If you can propose a working modification to support sending proper variable to PHP (FPM and Apache) level (Drupal) from the web server level, based on received (not set) HTTP headers, why not?

okay, I'll take a crack at this.

Here's a patch for the Nginx piece. It's about 4x longer than it should be, IMO, but subdirs.tpl.php reproduces the fastcgi_param blocks multiple times for some reason.

Fixes pushed to dev/3040646-https-proxy

Test procedure:

1. Deploy provision on the 3040646-https-proxy branch.
2. Verify the web server.
3. Install a site.
4. Add this debugging snippet to the site's local.settings.php:
   

   ksort($_SERVER);
   
   print "<div style=\"background-color: white;\">";
   foreach ($_SERVER as $key => $value) {
     print($key . " => " . $value . "</br>");
   }
   print "</div>";
   

5. Install ModHeader browser extension.
6. Visit the site; confirm that HTTPS header is being set to "off".
7. Set an X-Forwarded-Proto header in ModHeader to "foo" and refresh the site; confirm HTTPS header is still not being set to "on".
8. Set the header to "https" and refresh the site; confirm that HTTPS header is now being set to "on".
9. If it's working, css should stop working (because the browser will then try to load css via https which, presumably, isn't set up).

For ease of review, here's a patch.

FWIW, this is currently only matching "https". If a proxy is adding a X-Forwarded-Proto header with "HTTPS" or "Https" (for example) it won't match. I don't know whether this is likely. We can always match against an array instead.

Deploying this requires re-verifying Nginx servers, since it sets a variable in the server vhost that's then used in site vhosts. I suppose a hook_update_N() will be required to trigger this automatically. Should that be in hosting_nginx? I don't think it's required on Apache.

Branch works in my tests, but we still need that hook update.

Moving projects as the hook needs to be in Hosting. We can track both from Hostmaster.

I pushed a commit to a new `3040646-https-proxy` branch in Hosting that adds a hook_update_N(), to regenerate the Nginx server-wide vhosts.

With a clean dev VM, and pulling the branch here, a verify task doesn't get created from the command line with:

drush @hm updb

..but it does work from the front-end by hitting /update.php.

Can someone else confirm?