Avoid ROOT_URL and DDP_DEFAULT_CONNECTION_URL to default to localhost

[martijnwalraven]

The ROOT_URL and DDP_DEFAULT_CONNECTION_URL settings have turned out to be one of the more confusing parts of Meteor, especially when used with mobile clients. They are included in __meteor_runtime_config__ in the generated index.html and take their values based on environment variables or command options.

The main problem is that for mobile clients, subsequent updates delivered through hot code push replace the initially bundled index.html with a freshly generated one. This means the new settings depend on the environment set on the server at that point, and this could disable DDP and hot code push after the first update.

This is confusing, because something that initially worked will suddenly stop working without warning. We autodetect the ROOT_URL with certain commands, but let it default to localhost:<port> with others. (DDP_DEFAULT_CONNECTION_URL has no default for browser clients, but defaults to the value of ROOT_URL for mobile clients.)

For instance, meteor run ios-device or meteor run android-device will correctly set ROOT_URL to an autodetected external IP address. But if you run meteor run ios, meteor run android, or just meteor run, the ROOT_URL will default to localhost. So when a previously working app then reconnects and updates, it will receive a new index.html with the wrong settings and will no longer be able to connect to the server (and will never be able to again, because it won't receive hot code pushes).

This is not just a problem with mobile clients however, although the issues are more serious there. For a browser client, if you connect to the external IP address of a server started with meteor run, ROOT_URL will also default to localhost. That means the value of Meteor.absoluteUrl() will be wrong. You just don't notice it because we use relative URLs to refer to assets, and Meteor.absoluteUrl() isn't used in many other places.

Similarly, DDP_DEFAULT_CONNECTION_URL is not set by default for browser clients, and we then use Meteor._relativeToSiteRootUrl() rather than Meteor.absoluteUrl() to set the URL relative to the site the page was served from. For mobile clients this is not an option, because the URL the page was served from is the local web server. (There are also some known issues with relative DDP URLs that we may want to solve at some point, see comments in client_convenience.js and stream_client_common.js).

The solution is for the server to always be configured with the right external ROOT_URL. Using meteor deploy takes care of setting these values automatically, so there is no need to specify anything in that case. But when deploying on your own server or running in development, you have to make sure to set the ROOT_URL environment variable. This can also be controlled by passing the --server (for run) or --mobile-server (for build) options. (For build, we force you to specify the ROOT_URL when mobile platforms have been added to the project, but for run there is no such requirement.)

I'm not sure what the best way to deal with this is. In order to avoid these problems, it might be better to avoid defaulting to localhost in all cases. The downside of this is that it would also require an active non-local network interface in development. An alternative might be to still allow defaulting to localhost, but not bind to other network interfaces in that case.

[strikeout]

Hi!
Would it be possible to include the ROOT_URL_PATH_PREFIX in the DDP_DEFAULT_CONNECTION_URL?

Scenario:
I'm running three apps on the same server:port but use nginx location {} to seperate the apps (pretty successfully so far)

http://myserver.com:3000/ <- landingpage-app
http://myserver.com:3000/buyers/ <-buyers-app
http://myserver.com:3000/sellers/ <-sellers-app

when building the "buyers-app" with 1.3-cordova-preview I get the following:

// meteor build --server=http://myserver.com:3000/buyers/
ROOT_URL = "http://myserver.com:3000"
ROOT_URL_PATH_PREFIX: "/buyers"
DDP_DEFAULT_CONNECTION_URL = "http://myserver.com:3000"  
// always connects to the "landingpage-app", not the "buyers-app"

Seems like @gschmidt also noticed this issue in 12/2013
3a1e25f

[martijnwalraven]

@strikeout: This is out of scope for Meteor 1.3, but could you open a separate issue for this so we can track it?