Question

For our e-commerce service running on AppEngine we would like to offer the option for customers to run the stores on their custom domains (eg: http://www.mystore.com instead of http://www.enstore.com/mystore).

From a user perspective, I’d like them to enter the domain name they want to use in their preference screen and tell them how to configure their dns.

I know how you normally add domains to an AppEngine instance (through Google Apps) but I’m not sure you can automate that. And even if that’s possible they would be all (hundreds) listed on our google apps page.

Anyone know if this is possible/if there is a good way to do it?

Answer 1

I don’t think there is a way to add domains “programatically” to an AppEngine instance. Apparently, domains can only be added by using the Google Apps method that you described. This is confirmed in this SO post: How do i get foo.somedomain.com get handled by myapp.appspot.com/foo on appengine

The only options that pop to mind are the following:

• HTTP Redirection

  Many DNS providers support HTTP Redirection. In this case, your clients would be able to set up mystore.com and www.mystore.com to redirect to www.enstore.com/mystore. There are some obvious disadvantages with this method that might not be acceptable. First of all, with 301 and 302 redirects, the users will still be forwarded to the registered AppEngine URL: www.enstore.com/mystore, and it will show in their browser. In addition, choosing between a 301 and 302 redirect can make SEO tricky, since you’d have to get into how search engines behave with these redirects. For example most search engines will not use the original URL as a source for keywords when you use a 301 redirect.

  In addition to 301 and 302 redirects, some DNS providers (like DNS Made Easy) also provide what they call a “masked hidden-iframe redirect”. The page will render inside a hidden iframe, so the URL does not change in the user’s browsers. However this makes SEO even more tricky, and it will not allow users to bookmark internal pages, or to reference them easily.

  As you can see, this option is less than ideal, but it is one option to consider in some situations. Also note that at the moment, HTTP Redirection using 301 redirects is the suggested workaround for the Naked Domain Issue 777 on the AppEngine issue tracker.

• Reverse Proxy

  Another option could be to set up a small server somewhere else, like a small Amazon EC2 Instance, and set up a simple reverse proxy. You would be able to set this up very easily, just by using Apache and mod_proxy (or various other alternatives). This would allow you to ask your clients to set up a normal A Record pointing to this instance, while the Apache HTTP server would be acting as a proxy to your AppEngine.

  The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically set it up with one line like these for each VirtualHost (for each client domain):

  ProxyPass / http://www.enmystore.com/mystore/

  The configuration of the remote proxy could be easily handled by your back-end software.

  This is a neater solution which gives you plenty of control – but there are obviously some costs for these benefits. First of all, there is the expense to host the reverse proxy. You would also be adding another point of failure, so you have to add this to your high-availability plan. In addition, if you are serving some pages through SSL it can become quite complicated.