meteor/meteor — pull request #628 by awwx (2013-01-20 22:52:14+00:00)
Title: Protect users from getting stuck with an offline cached app

Have standard Meteor also return a 404 for /app.manifest, along with /favicon.ico and /robots.txt.

Rationale:

Suppose a programmer is using some "appcache" smart package (which serves an app cache manifest file) on a domain such as "foo.meteor.com". Later the programmer decides to stop using the "appcache" package and wants to go back to using stock Meteor. A user who previously had been using the app on foo.meteor.com and has it in their browser's app cache will see the following:

1. On navigating to "foo.meteor.com", the browser will first load the app from the app cache (without accessing the Internet), and so the user will at first be running the old version of the app.

2. The browser connects to the server and requests the app cache manifest, "/app.manifest". Note that even if the HTML of the new app served by stock Meteor doesn't contain the `` element which specifies using a manifest file, the browser doesn't know that yet because it hasn't requested the app web page ("/") yet.

3. The stock Meteor server (without this code change) returns the app html for "/app.manifest". The browser believes that the app is still being cached because it didn't get a 404, but since the format is invalid for an app manifest the browser ignores the contents and merely sends an app cache error event.

The user is now stuck. Pressing reload or force reload or restarting their browser does not get the browser off the old cached code. The user will continue to see the old cached app, forever, until they manually clear their browser's app cache.

Of course it would be easy enough to have a "manifest404" smart package that would specifically deliver a 404 for "/app.manifest". A programmer who had previously used an "appcache" smart package could substitute the "manifest404" package and their users would be fine. But it would mean that once any users had used an app cache on a domain such as "foo.meteor.com", that domain would now be "poisoned" in the sense that a stock Meteor without any added packages could never again be used safely on that domain. And that could be a support nightmare, where stock Meteor works everywhere... expect for a few users on a few domains who however long ago happened to use an app cache version of an app on that domain.

So for safety, it seems like not serving app_html for the app manifest is a good idea ^_^