backport of
#313145: Support X-Forwarded-* HTTP headers alternates →
When the trusted proxies are set and reverse_proxy is enabled, Symfony will automatically pickup the default X-Forwarded-* headers. However, Drupal only allows you to change the X-Forwarded-For header. Drupal does not support changing the name of any other header in the X-Forwarded family.
Taking, for instance, the X-Forwarded-Proto (XFP) header, which is included as part of the request sent to the back-end web server by many crypto-offloaders and load balancer. This header allows the load-balanced/crypto-offloaded application to know the protocol used by the client to reach the load balancer, allowing the application to generate links with the correct protocol. However, some systems use different headers for the same purpose. An example is the "Microsoft Internet Security and Acceleration Server", which uses the Front-End-Https for similar purposes.
<!--break-->
Benefit:
Without a correct scheme/protocol, various things break -- most visibly the stylesheets and javascripts, AJAX calls and the Drupal installer, because callback URLs are built on an incorrect scheme.
Cost:
The patch only introduces extra function calls for users already using a reverse proxy. Since that is not the case for most users, there is no cost for them.
Note:
It is possible to set $base_root manually in settings.php. But using this patch will allow Drupal to work in this sort of environment as it is already documented, without special care being taken to create settings.php ahead of time.
Beta phase evaluation
Manual testing steps
If you want to test this patch manually, without setting up Varnish, you must:
- Set up your webserver so it can serve requests over HTTPS.
- Set up your webserver so it adds an X-Forwarded-Proto header set to the value "https". In Apache, this looks like:
RequestHeader set X-Forwarded-Proto "https"
- Ensure your webserver is using the new configuration (e.g.:
sudo /etc/init.d/apache2 reload).
- Optionally, perform a fresh install of Drupal. Otherwise, have a working copy of Drupal.
- In
settings.php, ensure the #$base_url = 'http://example.com"; line is commented.
- In
settings.php, un-comment the $conf['reverse_proxy'] = TRUE; line.
- In
settings.php, un-comment the $conf['reverse_proxy_addresses'] = array(); line and add your client IP to the array (most likely 127.0.0.1).
- Flush all Drupal caches (e.g.:
drush -y cc all).
- Go to your example site over the HTTP protocol (e.g.: http://example.com). View the source.
- If the patch is applied and working correctly, all your stylesheets, scripts, etc. will use the https protocol.
Note that most links on the front page of a default Drupal installation are generated relative to the server root (e.g.: <a href="/user/login"></a>) so clicking on them will not generally take you to the HTTPS version (you'll need the
Secure Login →
or
Secure Pages →
modules for that).
- If the patch is not applied, or does not work correctly, all your stylesheets, scripts, etc. will use the http protocol.