Resolved Domain alias not respecting the 'Redirect with the HTTP 301 code' setting

[rickjelier]

Server operating system version

AlmaLinux 8

Plesk version and microupdate number

Plesk Obsidian Web Pro Edition 18.0.27

Hello,
I've been having a issue with setting up a domain alias:

I want a alias e.g. domain-extra.com that points to domain.com without any redirection (yes, I do know that this means I will get double content flagged by search engines - in this case it's the intended behavior)

How I try to do this is just very simply that I add the domain alias where I check the 'Web service' checkbox and uncheck the 'Redirect with the HTTP 301 code' checkbox.
When this is saved I still get a 301 redirect from Plesk, how is this possible?

 

[Bitpalast]

Possible causes:
a) After the configuration change the server reload interval has not expired yet, so the new configuration has not taken effect when you tested the behavior. Solution: Wait until the server reloaded the configuration.
b) The 301 is not generated by the web server, but by your website. For example some sites know their own URL, and if that does not exactly match the spelling your browser sends, the site will return an instruction where the browser shall reload the page, e.g. with www instead of w/o www or http --> https redirect. Solution: Sync the setting of the website regarding URL with the setting of the web server.

 

[rickjelier]

Hi Peter,
Thanks for your reply, I can safely say that both of these possibilities are not the case.
Are there any other possibilities?

 

[Kaspar]

Are there any other possibilities?

There aren't much opties left. If you've disabled redirect for your domain in Plesk, but you still get redirected then it's your browsers cache, the domain server config (htaccess or nginx rules) or you website/application.

 

[gennolo]

Hi Peter,
Thanks for your reply, I can safely say that both of these possibilities are not the case.
Are there any other possibilities?

I am facing the same issue trying to setup a domain alias for a Prestashop multistore environment on a Centos 7 Plesk box.

Redirect with the HTTP 301 code is turned OFF / Web service is turned ON

Despite this setting, domain2.com is always "301 redirecting" to domain1.com

Tried to restart all services with no success, I can confirm that this is not an application redirect, since the issue appears even by emptying the httpdocs dir.

 

[Peter Debik]

Do you have a "Redirect" directive in an .htaccess file? Is maybe the software itself sending it, because it knows that the URL wasn't right on which the page was requested (like Wordpress does it for example)?

 

[gennolo]

Hi @Peter Debik ,

I also thought that the redirection might have been depended on a application .htaccess, but as written, I have renamed httpdocs folder of the documentRoot to "httpdocs.bak" to perform a test and the problem persists - Browsing to domain2 causes an immediate 301-redirect to domain1.

So it seems like some server side misconfiguration to me.
if there's a way to figure out what the 301 redirect flag does "under the hood" I can provide some more information.

 

[Peter Debik]

There may be an .htaccess file in your subscription root, not in the document root.

You can see the content of the webserver configuration files in /var/www/vhosts/system/<your domain>/conf.

 

[gennolo]

By subscription root do you mean the "classical" /var/www/vhosts/domain1.com ?

Nothing special there, and no .htaccess file, there's just a website in httpdocs that must be shared by both domains :

ls -lha

drwx--x---. 8 subscription_user psaserv 4.0K Jan 17 12:01 .
drwxr-xr-x. 8 root root 4.0K Dec 18 11:36 ..
drwxr-xr-x. 3 subscription_user psacln 4.0K Dec 23 04:31 .composer
drwxr-xr-x. 2 subscription_user psacln 4.0K Sep 27 2021 error_docs
drwxr-xr-x. 31 subscription_user psaserv 28K Jan 16 17:50 httpdocs
drwx------. 2 subscription_user root 4.0K Jan 17 03:23 logs
drwxr-----. 3 subscription_user psacln 4.0K Sep 27 2021 .pki
drwxr-xr-x. 3 subscription_user psacln 4.0K Sep 27 2021 .revisium_antivirus_cache

In /var/www/vhosts/system/domain1.com/conf/httpd, inside the section
<VirtualHost SERVER_PUBLIC_IP:7081 >
</VirtualHost>

I can see various ServerAlias directive for the second domain :

ServerAlias "domain2.com"
ServerAlias "www.domain2.com"
ServerAlias "ipv4.domain2.com"

nginx configuration looks OK too, I guess :

server {
listen SERVER_PUBLIC_IP:443 ssl http2;

server_name www.domain1.com;
server_name ipv4.domain1.com;
server_name domain2.com;
server_name www.domain2.com;

....

so everything seems correct.

This is how the alias had been configured in Plesk


Anyway, "Synchronize DNS" makes no difference here since DNS is not managed on Plesk but externally.
Both domains have A records well-configured and pointing to the server's IP.

I am sure have already done this configuration in the past the same way without too much effort, but now I can't really figure it out..

I also thought the redirect might be due to this "Preferred domain" setting on the "domain1" , but it doesn't change anything

 

[Peter Debik]

O.k., got you, so the situation is that you created an alias, have turned 301 redirect off for that alias, the web server configuration files show the correct configuration, yet the server returns a 301 redirect once the software installed in the website is addressed. This indicates the the software itself is sending the 301 redirect. I probably detects the "wrong" URL coming in and responds with that redirect to have the browser redirect to the "correct" URL. Is there a setting the your software where you can turn such an option on or off?

It is clearly not a web server issue when there is no .htaccess rewrite and the domains are present as aliases in the web server configuration. You can try to reload the web server, just to make sure that there are no cache leftovers that cause a different behavior, but likely the redirect is sent by a script.

 

[gennolo]

After further testing, the issue appears to have been resolved "automagically" by adding directives to force the www / non-www redirect in the application's .htaccess file.

Honestly, I haven't fully understood the root cause of the problem, but during my attempts to reproduce it, browser cache or any cookies set by the application may have misled me, leading to incorrect deductions.

So yes, it's likely that the issue was on the application side, and the Plesk configuration is functioning correctly