Why is the HTTP version of this URL showing a different page than the HTTPS version?

Question

I'm doing some consulting work for a web development company's client, and this problem has me completely stumped.

The client has their Outlook setup to look at the url https://example.com/autodiscover/autodiscover.xml when setting up an account. In the past, the site had no autodiscover.xml, this would return a 404, and Outlook would instead try https://autodiscover.example.com/autodiscover/autodiscover.xml, which worked.

The site previously had no SSL certificate and would redirect to the http version, which would return a 404. However, after adding an SSL certificate, the https version of the link works, and the autodiscover.xml link instead returns

autodiscovery must be provided a valid email address

The non-HTTPS version correctly returns a 404 error, but the HTTPS version returns the string above. Why are the two returning different results when they're the same address? This has made entire email accounts for them inaccessible, so they are wanting a fix for this ASAP.

I've tried searching through all the files in the Wordpress installation to see if anything was causing this and couldn't find anything. The site is a reseller package from Hostgator, so the cpanel didn't seem to have any settings regarding disabling autodiscovery for Outlook. The .htaccess file didn't seem to have any rules in it that should be causing this, either.

I'm completely out of ideas and am tasked with making sure their email is working again ASAP. Any help is appreciated!

Answer 1

Your question is a little confusing, maybe you can structure it better. Anyways:

1. @Rob is right, HTTP and HTTPS work on different ports (80 and 443) and actually http://www.example.com and https://www.example.com are two completely different addresses. They can have different content as well if you want to.

2. It is possible that your Wordpress is making a wrong redirection. In that case I would recommend to force a single redirection from the http:// address to the https:// one using the .htaccess file. For more information on doing so you can check: https://stackoverflow.com/questions/1421068/htaccess-301-redirect-of-single-page

Answer 2

I had this issue too after SSL was recently enabled, with a minor difference in that https://clientsite.com/autodiscover/autodiscover.xml displays the error message "autodiscovery must be provided a valid email address" when browsed to and browing to http://clientsite.com/autodiscover/autodiscover.xml redirects to https://someserver.myhostingbusinessesdomain.com/autodiscover/autodiscover.xml and then gives the same error message.

In my role with a web agency providing the client's website at clientsite.com, I provided support to the client when their autodiscover stopped working for their Office365 account.

I tried adding a redirect command to the .htaccess file in the root of the site, but they weren't even being triggered for some reason. The request did reach the host account web server, or the Wordpress installation on it.

I still haven't discovered what is producing that error message, but what I did find was a DNS SRV record named _autodiscover._tcp that remained from before the client used Office365 and still pointed to the wrong autodiscover server someserver.myhostingbusinessesdomain.com

The record had details:

Name: _autodiscover._tcp
Port Number: 443
Host: someserver.myhostingbusinessesdomain.com
Priority: 0
Weight: 0

Port 443 is what's used by https (SSL), so I figured this could be relevant. The name _autodiscover._tcp means Service _autodiscover with Protocol _tcp

I updated the Host to the same value as for the autodiscover CNAME record, which was autodiscover.outlook.com (actually, the DNS tool I use in cPanel/WHM requires an extra . character on the end of the domain otherwise it automatically adds .clientsite.com to the end upon saving, but this behaviour differs by tool I understand)

After the TTL period, autodiscover appeared to work again (the client's Office365 account could be correctly autodiscovered again in Outlook 2016), although the same messages appear when browsing to the above given URLs for autodiscover.xml

I'm aware I don't have full knowledge of how autodiscover is setup, but since this worked for me hopefully this provides a solution for some cases for others too.

Interestingly Office365's tool for checking domain DNS health didn't pick up this problem!

Answer 3

You may have the same address but http and https work on different ports and should return different things unless they're configured otherwise. This is a server or Wordpress mis-configuration and I don't know anything about Microsoft crap so I can't help with that either.