I'm running ISPConfig 188.8.131.52 with nginx.
I noticed that the CGI variable SERVER_NAME lacks the www prefix, despite auto-subdomain being set to "www" and SEO redirect set to "domain.tld -> www.domain.tld".
My hunch is that given that SERVER_NAME can and should only contain a single server name string (and not both of the names that are defined in the nginx configuration), the server_name that's listed first is takes precedence and is used for the CGI SERVER_NAME value.
The vhost's nginx configuration file contains the following line (from ISPC's template, presumably):
server_name example.com www.example.com;
As stated above, SERVER_NAME takes the first value, "example.com".
Given that I've set auto-subdomain to www and the SEO redirect to www, does it not follow that the server_name values should be listed in the opposite order?
server_name www.example.com example.com;
The reason that this is a problem for me is that my PHP application compares the SERVER_NAME to a known, constant value, and if the two values don't match, a redirect to the correct domain, with https prepended, is performed. This eliminates "SSL certificate mismatch" warnings (provided that the domain has a proper certificate installed).
Due to the behavior that I describe, this logic fails and causes an endless redirection loop, because SERVER_NAME is "example.com" when the PHP constant is defined as "www.example.com".
Basically, I'm wondering if this is a "bug" and ISPConfig should swap the order of the server_name values in the nginx configration when the user has set auto-subdomain to www and set SEO redirect to www.
When I list the server_name values in the opposite order, with the www subdomain first, then the problem disappears and my application works correctly. This seems to confirm that nginx assigns the first value listed to the SERVER_NAME CGI variable.
Or, if there is some other way to achieve what I'm after, I am all ears.