1

I had 2 websites running on a server with 2 different hostnames. Lets call them

1 - hostname1.host.com

2 - hostname2.host.com

hostname1.host.com was bound to a WordPress site and hostname2.host.com was bound to a ASP.NET MVC site. Additionally, there were 2 more MVC sites that served as QA and staging on ports 8000 and 8008 respectively. These could naturally have been accessed through either hostname or simply on the server's IP address.

As of yesterday, the WordPress site is obsolete. I've bound the hostname1.host.com to the MVC site as this is the one I want to use and removed this hostname from the WordPress site's binding.

I have 2 global URL rewrite rules:

enter image description here

The first rule redirects all traffic with the server's ip address to hostname1.host.com except for ports 8000, 8080 and 8008.

The second rule redirects all traffic on hostname2.host.com to hostname1.host.com. I've also included the ports from this rule.

Then, on the live MVC site I also have a rule that redirects all port 80 traffic to 443:

enter image description here

The problem I'm having is wanting to bind the WordPress site to port 8080 which is not working. I have:

enter image description here

On my live site I have bindings (just imagine under the red it says hostname1.host.com):

enter image description here

What then happens when I try to access the WordPress site on any of the domains or the ip address on port 8080 is I get the redirect:

<h1>Object Moved</h1>This document may be found <a HREF="http://hostname1.host.com/">here</a>

This should not be happening. There should be no rule that redirects port 8080 to the hostname.

I can still access the staging and qa site's just fine. I've even tried swapping the QA site's port with the WordPress site's port. Then I can access the QA site on port 8080, but port 8000 redirects to the hostname.

From IIS logs:

There is a lot of this:

#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2016-11-24 12:27:57
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2016-11-24 12:27:57 192.168.3.7 GET / - 8080 - 169.1.87.250 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1687
2016-11-24 12:36:09 192.168.3.7 GET /Default/ChurchGroups - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1119
2016-11-24 12:36:17 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1157
2016-11-24 12:36:23 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1171
2016-11-24 12:36:35 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1156
2016-11-24 12:36:43 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1171
2016-11-24 12:37:06 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1147
2016-11-24 12:37:20 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1156
2016-11-24 12:37:32 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1140
2016-11-24 12:37:39 192.168.3.7 GET / - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1171
2016-11-24 12:38:11 192.168.3.7 GET /Default/Schools - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1187
2016-11-24 12:38:25 192.168.3.7 GET /Default/Schools - 8080 - 169.1.134.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.99+Safari/537.36 - 302 0 0 1185
Community
  • 1
Carel
  • 131
  • 7

1 Answers1

0

Can you post the IIS logs for when this happens? It sounds like there is a catch all in place somewhere and the IIS logs may contain more info depending on the logging level.

Richard Dakin
  • 101
  • 2
  • I've posted some lines from the logs. I don't see anything that would indicated redirection. – Carel Nov 24 '16 at 12:45