I think I’ve solved the problem (hopefully).
In nginx config you have to set everything except the JS and CSS files to be Cache-Control no-store, because if you are using a router the main HTML file can be loaded from multiple locations.
I have two location blocks, one: location / {
And the other: location ~ /.*\.(css|js)$ {
Both have the proxy lines in. The first has add_header Cache-Control no-store;.
Let me know if this works for you.
Wondering if Galaxy has this problem too, since users don’t set nginx stuff for Galaxy.
I will give your solution a try tomorrow.
I’ve experienced this problem on Galaxy.
Both have the proxy lines in. The first has add_header Cache-Control no-store;.
I think that this disables client caching at all. As a result the bundled js gets downloaded everytime, a deal breaker for mobile / low-bandwidth environments.
It doesn’t. pad pad pad
You are right @topicly
I misunderstood
and just set cache-control on my single / location.
I just copied the content from / to ~ /.*\.(css|js)$ and added add_header Cache-Control no-store; to /
I’ve no idea if it works (will update to this thread), but js and css files are cached now.
This did not solve the problem, it’s still refreshing.
Finally I’ve found a working solution. According to https://github.com/meteor/meteor/issues/5769#issuecomment-215977417 nginx must not handle any caching at all.
This was the location block which caused refresh loops:
location / {
proxy_pass http://app;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket specific
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# this setting allows the browser to cache the application in a way compatible with Meteor
# on every applicaiton update the name of CSS and JS file is different, so they can be cache infinitely (here: 30 days)
# the root path (/) MUST NOT be cached
if ($uri != '/') {
expires 30d;
}
}
A lot tutorials and boilerplates advise to use this faulty configuration
if ($uri != '/') {
expires 30d;
}
which is actually the problem. So just delete it.
Working configuration:
location / {
proxy_pass http://app;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket specific
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
I’ve been having this problem on mobile/android but not on OSX laptop - so hey I looked through my code for this nginx if ($uri != ‘/’) { expires 30d; } but I couldn’t find it. What file is this in? And if this isn’t a part of my project and I’m having the same problem, it could be something else. What’s up? Thanks for your help everybody! I’m new-ish to meteor and deployed my first app (a very simple one) today.
I just tried adding appcache to my project and got an infinite reload locally. I wonder if this has anything to do with the issues. For now I’ve just removed appcache.
Just another datapoint on this. We recently updated our 1.2.x app to 1.4 (we tested 1.3, but not in production). We are seeing constant reloads whenever we run our app after using ‘meteor build’, but not if we run it using ‘meteor run’. I can replicate this on my own laptop (OSX) as well as on out development testing servers (dockerized debian). Neither are using a proxy.
Point is, even if it is affected by nginx, nginx isn’t the cause.
I’m wondering if it is loading-order issue as I’ve seen some peculiarities in our logging that makes me think class may be being instantiated before they are defined. I’m seeing objects that just aren’t there, even though they should be created at startup and that is showing in our logs as empty arrays, for example. Strange stuff and it takes a long time to track down because I have to do a full build each time I want to test. ( What is this, C++? lol )
Well that’s great news if you can produce a reliable reproduction of the
problem. Would be worth posting the issue on github and finally getting
someone from MDG to look into it.
Maybe I spoke too fast. I upgraded my local mongo install to 3.2.9 (was 2.6) and now it has suddenly stopped. I’m going to try on our development testing server to see if it still has the problem (it is still running mongo 2.6). If it is, at least we’ve isolated one possible cause of the problem.
Was there any more update on this issue? We are also experiencing this with our Production application and it causing some frustration for our users 
We have removed the caching from our nginx configuration file but it did not seem to help…
I have still been seeing it on my site when deploying to a subdomain, but
not to the regular domain.
It’s an extremely painful problem and no one seems to have come up with a
solution.
But surely, this is a pretty new issue. As of 1.3, or around there - right?
Yup. Pretty it’s sure 1.3 and on, but you can check the thread if anyone
has had the issue with 1.2
We do not see it, is there any kind of reproduction? Any idea of maybe which packages might influence this?
After much frustration, I might have found a solution. In Kadira I saw that “meteor_autoupdate_clientVersions” was call the most frequent. Autoupdate is responsible for: “When it sees that a new version is available, it uses the reload package (if included in the app) to gracefully save the app’s state and reload it in place.”
When I disabled the Hot Code Push (HCP) on the client side Meteor._reload.onMigrate(function() {return [false];}); by overwriting the reload function, the problem seems to be solved.
Not really sure what triggers the HCP on our production server. But it seems to be a client issue. Can’t spot any errors w.r.t. console / http/s / ssl etc…
Initially the reload.js was spotted in the Network tab of the console:
So assuming this fixes things. Does this mean the app will only update each
time the client comes to the site a new or refreshes themselves?
Yes. But for a production app I don’t think that is a problem
