Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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: <a href="https://stackoverflow.com/questions/976127/">How do i get foo.somedomain.com get handled by myapp.appspot.com/foo on appengine</a></p> <p>The only options that pop to mind are the following:</p> <ul> <li><p><strong>HTTP Redirection</strong></p> <p>Many DNS providers support HTTP Redirection. In this case, your clients would be able to set up <code>mystore.com</code> and <code>www.mystore.com</code> to redirect to <code>www.enstore.com/mystore</code>. 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: <code>www.enstore.com/mystore</code>, 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. </p> <p>In addition to 301 and 302 redirects, some DNS providers (like <a href="https://www.dnsmadeeasy.com/" rel="nofollow noreferrer">DNS Made Easy</a>) 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.</p> <p>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 <a href="http://code.google.com/p/googleappengine/issues/detail?id=777" rel="nofollow noreferrer">Naked Domain Issue 777</a> on the AppEngine issue tracker.</p></li> <li><p><strong>Reverse Proxy</strong></p> <p>Another option could be to set up a small server somewhere else, like a small <a href="http://aws.amazon.com" rel="nofollow noreferrer">Amazon EC2 Instance</a>, and set up a simple <a href="http://en.wikipedia.org/wiki/Reverse_proxy" rel="nofollow noreferrer">reverse proxy</a>. You would be able to set this up very easily, just by using Apache and <a href="http://httpd.apache.org/docs/2.0/mod/mod_proxy.html" rel="nofollow noreferrer">mod_proxy</a> (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. </p> <p>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 <code>VirtualHost</code> (for each client domain):</p> <p><code>ProxyPass / http://www.enmystore.com/mystore/</code></p> <p>The configuration of the remote proxy could be easily handled by your back-end software.</p> <p>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.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload