Reverse proxy and auto_complete with mixed content

I have an apache configuration with reverse proxy (IP of this server: 192.168.1.82) to handle my new D9 server:

192.168.1.82 : 443 is passed to 192.168.1.87 as HTTP(80)

<VirtualHost *:443>
    ServerName www.mydomain.be
    ServerAlias mydomain.be
    NameVirtualHost www.mydomain.be

    ProxyPreserveHost On
    ProxyPass / http://192.168.1.87:80/
    ProxyPassReverse / http://192.168.1.87/
    SSLProxyCheckPeerCN Off
    SSLProxyCheckPeerName Off
    SSLProxyVerify none
    ...
</VirtualHost>

I think it is called SSL Termination

192.168.1.82 : 80 is redirected as https (443)

<VirtualHost *:80>
    ServerName www.mydomain.be
    Redirect permanent / https://www.mydomain.be/
</VirtualHost>

192.168.1.87 : settings.php

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = [
  '192.168.1.82',
];
$_SERVER['HTTPS'] = 'on';
$settings['ssl'] = TRUE;

Unfortunately the autocomplete feature of an entity reference field request a non https (unsecure) endpoint (Mixed content):

http://www.mydomain.be/fr/entity_reference_autocomplete/node/default:node/3veI...I?q=t

What can I do to force the https... I will accept the most ugly hack if it is working (yes, I am here)

Test 1: ProxyPass https instead of http [will not work, see below]

I have adapted the 82 virtual host as follow;

SSLProxyEngine on
ProxyPass / https://192.168.1.87/
ProxyPassReverse / https://192.168.1.87/

=>This time I don't have the mixed content problem, but I have ERR_TOO_MANY_REDIRECTS again for this entity autocomplete endpoint

Test 2: hack Symfony\Component\HttpFoundation\Request::isSecure()

Here is my new isSecure() function:

public function isSecure(){
  return TRUE;
}

By doing this, the autocomplete url use https, but this time, I got ERR_TOO_MANY_REDIRECTS

GET https://www.mydomain.be/fr/entity_reference_autocomplete/node/default%3Anode/3ve...I?q=T net::ERR_TOO_MANY_REDIRECTS

I have really no clue from where it can come

The htaccess file in Drupal should be able to force all traffic as HTTPS. There are some comments in the file, but something like this should work (used in several projects):

  # Force all traffic to HTTPS, except a local instance
  RewriteCond %{HTTPS} off
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteCond %{HTTP_HOST} !^local\.dev\.domain$ [NC]
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]




  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /

The third line is optional - it would exempt a local dev environment from the rewrite. If you use a local SSL, you can omit that line.

If Apache is serving all requests, it will pass through these rules, evaluate them and do the rewrite.

You can test rules here: https://htaccess.madewithlove.com/

Here is the test: https://htaccess.madewithlove.com?share=69ce1303-b1af-4041-aecf-a32f2ecd1bfb

Try to set X-Forwarded-* headers in the Apache reverse proxy:

<VirtualHost *:443>
    ServerName www.mydomain.be
    ServerAlias mydomain.be
    NameVirtualHost www.mydomain.be

    ProxyPreserveHost On
    ProxyPass / http://192.168.1.87:80/
    ProxyPassReverse / http://192.168.1.87/

    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

These are the headers which the reverse proxy configuration in settings.php needs.

You can check the presence of the headers at www.mydomain.be/admin/reports/status/php in the section HTTP Headers Information

In such a setup using X-Forward-* headers is the general approach to allow Drupal to build absolute links with the correct protocol to avoid the mixed content error.

However, Drupal pages can be built completely with relative links and this is how Drupal is setup out-of-the-box, including core autocomplete fields. So you could review autocomplete routes in contrib/custom code and remove the absolute option to make them relative.

Redirecting

To avoid further commenting, Drupal doesn't redirect, out-of-the-box. Redirecting is not connected to the issue, it only makes it harder to debug. It's impossible to tell from afar which code you might have implemented which is redirecting. It could also be that the redirects are still cached, permanent redirects get cached for weeks, even if you have removed the redirect code.