CGI variable SERVER_NAME lacks the www prefix despite auto-subdomain and SEO redirect

Hello,

I'm running ISPConfig 3.0.5.2 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):

Code:

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?

Code:

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.

Thanks!

 

Ah, I see. So, all I need to do is add the www to the main domain name for the website and the problem will be solved.

My only other question is whether or not including the www subdomain in the main domain name will change the behavior of either a) setting auto-subdomain to "www", and/or b) setting SEO redirect to "domain.tld -> www.domain.tld"; does the main domain value have any effect on the behavior of those settings?

Thanks for clarifying, Till!

 

Okay, so I modified the main domain name so that it includes the www. To be clear, I changed it from "example2.com" to "www.example2.com" in the Clients -> Domains interface.

(It is important to note that I have www.example1.com on this server, too, which is a completely unrelated domain.)

This "fixes" the problem of the CGI "SERVER_NAME" variable lacking the www prefix (it now reflects "www.example2.com", as expected), but there is an unintended side-effect: SEO redirects no longer function as expected.

After making this change, if I try to browse to example2.com (without the www), the SEO redirect, which I have set to "domain.tld => www.domain.tld", is not effective.

Not only is the redirect not effective, but browsing to example2.com redirects me to example1.com, which is a very bad scenario in a production environment. Visitors to one client's site see a different client's site.

I assume that this occurs because a symlink for example2.com doesn't actually exist in /etc/nginx/sites-available (nor should it; the symlink name is now www.example2.com), so nginx redirects the request to the "first domain, alphabetically, with a '100-' prefix" with no regard whatsoever for any SEO redirect that might be set for www.example2.com (e.g., "domain.tld => www.domain.tld").

Is this a case of "operator error"? Or is this an actual problem/bug?

Again, all I want is for the CGI variable "SERVER_NAME" to include the "www" prefix, without having to include the www subdomain in the main domain name. Not only is including the www in the main domain name redundant when SEO redirect is set, but doing this causes the SEO redirects to stop functioning altogether.

I suppose my only option is to add custom nginx configuration directives to set the SERVER_NAME manually, e.g., change:

Code:

fastcgi_param	SERVER_NAME		$server_name;

to

Code:

fastcgi_param	SERVER_NAME		www.$server_name;

(I haven't actually tested the above syntax, either.)

 

A quick follow-up after making some progress.

With the objective "to redirect requests for all subdomains (other than www) to www subdomain", I was able to fix all of the "unexpected" SEO redirection issues by setting Auto-Subdomain to "*." and setting SEO Redirect to "* => www.domain.tld.

As it turns-out (and as usual), ISPConfig is behaving "correctly".

That leaves just the SERVER_NAME CGI variable problem. With the above settings, the server_name directive looks like this:

Code:

server_name example2.com *.example2.com;

When I var_dump() the $_SERVER['SERVER_NAME'] from within PHP, the value is example2.com. (I should note an important correction to an assumption made in my initial post: it seems that nginx doesn't always use the first server_name value in a list of several values; unfortunately, I don't know by what criteria nginx decides which value to assign to its $server_name configuration variable, which is later passed to CGI.)

Of course, as stated previously, I need this value to be www.example2.com, in order to secure my application against misconfiguration or malice.

I was able to do this by overwriting and hard-coding the fastcgi_param that is defined within ISPC's nginx vhost template:

Code:

location @php {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_param	SERVER_NAME		www.example2.com;
            # [...]
}

Obviously, this approach is unacceptable because ISPC will overwrite the change whenever the vhost is modified via the GUI.

Ultimately, I am wondering if there is a "correct" means by which to achieve the same. I'm failing to see how I might overwrite the SERVER_NAME value within the vhost's "nginx Directives" field, given that the "location @php" block is already closed by the time those directives are written to the configuration file.

Thanks again, Till.

EDIT:

I'm all set, regarding the SERVER_NAME value; the following works:

Code:

fastcgi_param	SERVER_NAME		www.$server_name;

 

Thanks for the info, Till.

Does the snippet you provided go into the ISPConfig nginx configuration template? Or somewhere else?

If it goes into the template, I assume that the settings will apply to all vhosts. I need to change the hard-coded SERVER_NAME for each vhost; am I out of luck?

EDIT:

This seems to work, regarding the SERVER_NAME value being generated dynamically:

Code:

fastcgi_param	SERVER_NAME		www.$server_name;