Domain redirection with momentary "not available" message

Question

To redirect my naked/bare domain to my www domain which is hosted at Heroku, I am using the GoDaddy forwarding feature as mentioned in other posts (Forward to www.mydomain.com, 301 (Perm) redirect, Forward only):

• 301 Redirect vs. Domain Fowarding GoDaddy
• https://stackoverflow.com/a/11494197/317110

Also the domain details screen is set: Cname (Alias), host: www points to myapp.heroku.com.

While this mostly works, when I visit "mydomain.com" with OSX Chrome, I momentarily see the gray "This webpage is not available" screen before the redirection occurs. Sometimes the delay may even be a few seconds -- long enough that a user might navigate elsewhere before it occurs. (On Safari it works fine).

My site is: www.morphmarket.com. Try that versus morphmarket.com.

Is this to be expected with the approach I'm using, and can it be avoided?

Update

50.63.202.10 is GoDaddy. So @ (bare) points at GoDaddy, which resolves it to www, then www is resolved using the CName record to some Heroku IP address. Therefore @ takes an extra roundtrip. Additionally, there's a single GoDaddy IP whereas Heroku has many IPs all over the world, presumably providing a faster response that area.

Seems like if the bare domain could have a CName like record we'd be set, but there are probably good reasons why it can't, such as that other things are going on here as well like email handling.

Answer 1

What a great question...

Considering your setup I'm not what you can do here.

It looks like the delay is on Godaddy's 301 redirect side so I'd be tempted to ask them why there's such a delay.

Your A record points to 50.63.202.10, is that a hosting account? If so then I'd be tempted to remove the godaddy redirect and allow the non-www to go to the godaddy hosting on IP 50.63.202.10, then 301 redirect from there.

That may or may not speed up the redirect but worth trying. Well for me it is.

@WilliamHarvey

Answer 2

You seem to be doing everything right webmastering wise, but I took a look at your headers using CURL.

When I tried just http://morphmarket.com, I got the following:

HTTP/1.1 301 Moved Permanently
Cache-Control: max-age=900
Content-Length: 0
Content-Type: text/html
Location: http://www.morphmarket.com
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 19 Aug 2015 01:17:29 GMT
Age: 1
Connection: keep-alive

And this is what I got when I tried http://www.morphmarket.com

HTTP/1.1 200 OK
Connection: keep-alive
Date: Wed, 19 Aug 2015 01:17:49 GMT
Server: WSGIServer/0.1 Python/2.7.10
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Vary: Cookie
Set-Cookie:  csrftoken=ro6q7diFWPnnIuvBSxXWWJUnSfqEbzDb; expires=Wed, 17-Aug-2016 01:17:49 GMT; Max-Age=31449600; Path=/
Via: 1.1 vegur

This tells me that you are using two different servers. Microsoft IIS to handle the domain without WWW and a different server to handle the domain with www. Also there are too many HTTP headers for the redirect page.

The HTTP headers for a standard apache redirect page are similar to this:

HTTP/1.1 301 Moved Permanently
Date: Wed, 19 Aug 2015 01:21:58 GMT
Server: Apache
Location: http://www.example.com/
Content-Type: text/html; charset=iso-8859-1

My suggestion then is to change the version of IIS you are using or change the whole server software that serves the domain without the www. In fact, try to make the server software consistent when handling both the www and non-www versions of your domain.

Answer 3

Heroku gives directions on configuring DNS for root and they provide a list of DNS providers who can provide ALIAS/ANAME and other capabilities needed.

They say, if your DNS provider will not provide this, then you have to do a redirect (just as I have done):

If your DNS provider does not support ALIAS or ANAMEs, you will need to use subdomain redirection (also called a forward) for configuring DNS for a root domain (you cannot use an A record, which requires an IP address). Subdomain redirection results in a 301 permanent redirect to the specified subdomain for all root domain requests. However, be aware that, using this method, a secure request to the root domain, e.g., https://example.com, will result in an error or warning being displayed to the user or the connection may be refused altogether.

From this I infer the answer to my question -- Chrome is likely first trying to resolve "morphmarket.com" as https, then shows the error, then tries http and it works.

As to why it's so slow, the factors I believe are:

• @/bare requires an extra round trip for GoDaddy to redirect to the subdomain.
• GoDaddy is stated by some to be slow.
• If Chrome is actually trying https first, this may mean 2 extra round trips.
• All IPs are pointed to a single GoDaddy IP, whereas the CNAME redirects to many Heroku servers around the world.

Sounds like the fix is that I'll be transferring my domain to a DNS provider with ALIAS/ANAME capabilities.