If we use `__meteor_runtime_config__.ROOT_URL` directly, as we were
previously, then we end up sending Cordova clients to http:// URLs even
if force-ssl is being used in the app. This is fairly bad on its own
(always sending cordova clients to http:// URLs instead of https://),
but made even worse by the fact that we don't set CORS headers on
force-ssl redirects (that is, the app breaks completely if the client
makes a DDP connection to an http:// URL for a force-ssl app).
If we use `__meteor_runtime_config__.ROOT_URL` directly, as we were
previously, then we end up sending Cordova clients to http:// URLs even
if force-ssl is being used in the app. This is fairly bad on its own
(always sending cordova clients to http:// URLs instead of https://),
but made even worse by the fact that we don't set CORS headers on
force-ssl redirects (that is, the app breaks completely if the client
makes a DDP connection to an http:// URL for a force-ssl app).
So far I have only removed files from packages that are included by
default in newly `meteor create`d projects. We should probably make a pass
over all the core packages, too.
The server sends hot code push updates to mobile clients with ROOT_URL
and DDP_DEFAULT_CONNECTION_URL taken from the MOBILE_ROOT_URL and
MOBILE_DDP_URL environment variables. These are set by the main meteor
process when it starts the app runner.
When you set ROOT_URL_PATH_PREFIX, source maps are not found because the server serves them at a different path from where the client looks for them.
I don’t understand this code super well, but based on what’s reported in issue #2627, the new code seems strictly more correct than the old code.
Parse as decimal (which means you can't specify --parent-pid in hex,
that's fine). And convert back to string to check that the whole string
was parsed as an int (i.e. "123foobar" should not be converted to
"123").
Thanks Slava and Avital.
If you pass "--parent-pid foobar", then we immediately log an error
message and exit. This check happens via `parseInt` rather than testing
for exceptions in `process.kill(parentPid, 0)` because `process.kill`
converts its pid argument to an integer, so `process.kill('foobar', 0)`
returns true just as `process.kill(0, 0)` does.
Downsides:
* Doesn't catch the case where the parent is CPU-hogging (but maybe we
don't want to catch that case anyway, since the bundler not yielding
is what's causing #2536).
* Could be fooled by pid re-use, i.e. if another process comes up and
takes the parent process's place before the child process dies.
Untested so far because I haven't been able to actually kill a parent
process in such a way that the child stays alive.
We were not passing html attributes through to the Boilerplate object,
so appcache manifest was never showing up in the <html> tag. Add
'extraData' to `Boilerplate.toHTML` so that we can specify the html
attributes at request time.
