Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hot Code Push broken on iOS #10277

Open
EliArtist opened this issue Oct 13, 2018 · 133 comments
Assignees
Milestone

Comments

@EliArtist
Copy link

@EliArtist EliArtist commented Oct 13, 2018

My iOS app can't use hot code push to get new versions I upload. After some searching I believe I can narrow down the problem to a bug in cordova-plugin-meteor-webapp which tries to link the same file twice. I'm pretty sure that is what breaks hot code push.
I found a similar issue here: https://github.com/meteor/cordova-plugin-meteor-webapp
But that repository is untouched since February so I decided to open a new issue here.

My current Meteor version is 1.7.1-rc.5, I'll try to update the meteor version to 1.8, test again and post an update here.

EDIT:
After trying to build an iOS App with Meteor 1.8 I'm getting the same error

@dovydaskukalis

This comment has been minimized.

Copy link

@dovydaskukalis dovydaskukalis commented Oct 13, 2018

Same issue, it stops working every time we update font files. Same error message as in meteor/cordova-plugin-meteor-webapp#56.

@menelike

This comment has been minimized.

Copy link

@menelike menelike commented Oct 15, 2018

Also related to meteor/cordova-plugin-meteor-webapp#59

Right now we need to release a new app version on font updates.

@fizx1

This comment has been minimized.

Copy link

@fizx1 fizx1 commented Oct 15, 2018

I was about to post a separate bug report, but ours seems like it could be the same issue. I'll post our details below. We are eager to see this working and willing to help out however possible. Thanks!

We are having some issues with Hot Code Push. In short, we are deploying to Galaxy using a Windows PC. We use that same PC to build the Android/Cordova apk. Hot Code Push works for these Android clients. Hot Code Push doesn't work, though, for iOS clients -- the iOS client is built on another machine. We are using the METEOR_CORDOVA_COMPAT_VERSION system, so it should work, from my understanding. There are no apparent error messages (maybe I'm not looking in the right place), but when I redeploy a new app version to Galaxy, only Android clients process the update. Thanks in advance and please let me know how I can help further.
The long version...
We are deploying from a Windows machine to Galaxy using the following commands:

SET DEPLOY_HOSTNAME=galaxy.meteor.com
SET METEOR_CORDOVA_COMPAT_VERSION_ANDROID=v0001
SET METEOR_CORDOVA_COMPAT_VERSION_IOS=v0001
meteor deploy appname.meteorapp.com --settings settings.json --mobile-server=https://appname.meteorapp.com

The hot code push version number is confirmed to be making it to the Galaxy server; we can see the file http://appname.meteorapp.com/__cordova/manifest.json is visible and contains the entry:
"cordovaCompatibilityVersions":{"android":"v0001","ios":"v0001"}

We are building for iOS App Store with the following command:
METEOR_CORDOVA_COMPAT_VERSION_IOS=v0001 meteor build build_directory --server https://appname.meteorapp.com

After building, we open the build in XCode, create an archive, and upload the archive to the App Store for approval and release.
(please PM me for the actual appname, thanks!)

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Oct 25, 2018

Anybody figured how to workaround this bug?

@fizx1

This comment has been minimized.

Copy link

@fizx1 fizx1 commented Oct 25, 2018

@dovydaskukalis

This comment has been minimized.

Copy link

@dovydaskukalis dovydaskukalis commented Oct 25, 2018

@fizx1 We always deploy from the same machine and manually specify compatibility version in config file, same issue.

@sugoke

This comment has been minimized.

Copy link

@sugoke sugoke commented Oct 25, 2018

Same issue here. I have an app deployed on heroku, and when I build for iOS, HCP seems to be broken. I have seen a few messages regarding this “bug” on other forums but no real explanation.

`2018-10-18 12:40:36.942203+0200 Premia[1933:140955] Serving asset bundle version: 3e53d8a74f99d185edd94272536b033999610f80

2018-10-18 12:40:39.200604+0200 Premia[1933:140955] Start downloading asset manifest from: manifest.json -- https://premia.herokuapp.com/__cordova/

2018-10-18 12:40:40.369383+0200 Premia[1933:141234] Downloaded asset manifest for version: 9c4c53cdc986cd3eb49b9f99b097a1bb76305b42

2018-10-18 12:40:40.370495+0200 Premia[1933:141234] Download failure: Skipping downloading blacklisted version

**2018-10-18 12:40:40.374600+0200 Premia[1933:140955] ERROR: {"line":36,"column":30,"sourceURL":"http://localhost:12224/plugins/cordova-plugin-meteor-webapp/www/webapp_local_server.js"}**`

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Oct 26, 2018

@benjamn, we would like to ask some guidance regarding this?

@RealHandy seems to have some clues on what's happening here: meteor/cordova-plugin-meteor-webapp#56

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Nov 2, 2018

Just saw these related PRs - hope they made it to 1.8.1.beta soon

meteor/cordova-plugin-meteor-webapp#61
meteor/cordova-plugin-meteor-webapp#62
#10219

@Wade-BuildOtto

This comment has been minimized.

Copy link

@Wade-BuildOtto Wade-BuildOtto commented Nov 14, 2018

I am seeing the same issue on 1.7.0.4 with METEOR_CORDOVA_COMPAT_VERSION_IOS in use, its ignoring it even though what is listed on the manifest is accurate. I might role back to see if that helps, but it's starting to get costly rolling out small fixes via app store updates.

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Nov 16, 2018

The PRs related to the cordova-plugin-meteor-webapp has been merged to master! Wohoo!

For those who wanted to follow the PR for the main meteor project related to HCP and other cordova stuff, subscribe to this PR:
#10339

@RealHandy

This comment has been minimized.

Copy link

@RealHandy RealHandy commented Nov 16, 2018

BTW, this is also issue #10181. See meteor/cordova-plugin-meteor-webapp#59 for the PR. The code there works if you need it right away, but it was done in a way to highlight the problem for determining a proper fix, which @benjamn is now doing (yay!).

@Wade-BuildOtto

This comment has been minimized.

Copy link

@Wade-BuildOtto Wade-BuildOtto commented Nov 21, 2018

has anyone tried meteor update --release 1.8.1 to see if the update fixes the issue.

"Not it."

@Wade-BuildOtto

This comment has been minimized.

Copy link

@Wade-BuildOtto Wade-BuildOtto commented Nov 30, 2018

any movement on this?

@sugoke

This comment has been minimized.

Copy link

@sugoke sugoke commented Dec 1, 2018

Interestingly, the problem occurs only when deployed (to Heroku) on my side. On localhost, HCP works. 1.8.0.1 did not fix.

@macrozone

This comment has been minimized.

Copy link

@macrozone macrozone commented Dec 13, 2018

I can also confirm that this is completly broken on IOS.

I get the error

Error: Could not link to cached asset: Error Domain=NSCocoaErrorDomain Code=516 "“315ECD_9_0.ttf” couldn’t be linked to “webfonts” because an item with the same name already exists." UserInfo={NSSourceFilePathErrorKey=/var/mobile/Containers/Data/Application/239C2D9C-6CF1-4DF0-9964-B63372F459CA/Library/NoCloud/meteor/PartialDownload/app/webfonts/315ECD_9_0.ttf, NSUserStringVariant=(
    Link
), NSDestinationFilePath=/var/mobile/Containers/Data/Application/239C2D9C-6CF1-4DF0-9964-B63372F459CA/Library/NoCloud/meteor/Downloading/app/webfonts/315ECD_9_0.ttf, NSFilePath=/var/mobile/Containers/Data/Application/239C2D9C-6CF1-4DF0-9964-B63372F459CA/Library/NoCloud/meteor/PartialDownload/app/webfonts/315ECD_9_0.ttf, NSUnderlyingError=0x2812c3c90 {Error Domain=NSPOSIXErrorDomain Code=17 "File exists"}}

and i definitly did not add any assets!

@macrozone

This comment has been minimized.

Copy link

@macrozone macrozone commented Dec 19, 2018

Interestingly, the problem occurs only when deployed (to Heroku) on my side. On localhost, HCP works. 1.8.0.1 did not fix.

yes, on develop it works, but not once you deployed it.

@bmanturner

This comment has been minimized.

Copy link

@bmanturner bmanturner commented Dec 19, 2018

I upgraded from 1.6 to 1.8, and HCP didn't work even though I used the compatibility override. I had to immediately rollback.

Is this the correct issue for what I experienced?

@macrozone

This comment has been minimized.

Copy link

@macrozone macrozone commented Dec 19, 2018

I upgraded from 1.6 to 1.8, and HCP didn't work even though I used the compatibility override. I had to immediately rollback.

Is this the correct issue for what I experienced?

yes, i think so. I noticed too late and can't roll back easily now :-(

@bmanturner

This comment has been minimized.

Copy link

@bmanturner bmanturner commented Dec 19, 2018

@sugoke

This comment has been minimized.

Copy link

@sugoke sugoke commented Dec 19, 2018

@RealHandy

This comment has been minimized.

Copy link

@RealHandy RealHandy commented Dec 19, 2018

Yes, this is all the same issue: see also #10181. The underlying issue is at meteor/cordova-plugin-meteor-webapp#56

Note: I've just uploaded what I think is an improved workaround: meteor/cordova-plugin-meteor-webapp#59

Update: I have provided in the PR (see link above) some instructions on how to implement this.
If you know how to get the forked PR version, put it on your local drive, and make that the version in your project, you can use this to fix the problem, but it does require that you push a new iOS version out to users with the fix in it.

@bmanturner

This comment has been minimized.

Copy link

@bmanturner bmanturner commented Dec 19, 2018

@RealHandy So there is no way to update a server from 1.6 to 1.8 without also publishing client updates to the app stores? I've never had to do that when upgrading meteor in the past.

@RealHandy

This comment has been minimized.

Copy link

@RealHandy RealHandy commented Dec 19, 2018

@bmanturner This bug is related to changes to assets. If the upgrade causes some asset change, then the bug will bite you on iOS and hot code push will fail (as described in the posts across the various related issues and as seen in @macrozone's post above (#10277 (comment)). If HCP is failing, the workaround can only be applied by an update to the user's phone version, since the bug fix is in cordova code.

For example, "webfont.ttf" is in my /__cordova/manifest.json file twice. See the difference between the two lines in bold:

{"path":"packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf","where":"client","type":"asset","cacheable":false,
"url":"/__cordova/packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf",
"size":138204,"hash":"ae832c436a36bdb3b60c1a7fcab1349fd9a5e3d8","sri":"a+iafir/sdUB+O+VSL7/Xlb6AA45KL4fOfmsaW9Nvm1qkIgx3P+L0R6Lw4OTTLMordHfCo6rty9ZhAq8xAyBig=="},

{"path":"packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf","where":"client","type":"asset","cacheable":false,
"url":"/packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf",
"size":138204,"hash":"ae832c436a36bdb3b60c1a7fcab1349fd9a5e3d8","sri":"a+iafir/sdUB+O+VSL7/Xlb6AA45KL4fOfmsaW9Nvm1qkIgx3P+L0R6Lw4OTTLMordHfCo6rty9ZhAq8xAyBig=="},

This is causing the HCP failure, and you need the workaround to get past the failing behavior caused by these assets being in the manifest twice.

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Jan 11, 2019

Fix to iOS HCP has been committed. Excited to test this early next week

#10248 (comment)

@benjamn

This comment has been minimized.

Copy link
Member

@benjamn benjamn commented Jan 11, 2019

Note: to test these changes, you'll need to run meteor update --release 1.8.1-beta.13 first.

Thanks especially to @RealHandy for finding an elegant solution! meteor/cordova-plugin-meteor-webapp#59

@benjamn benjamn added this to the Release 1.8.1 milestone Jan 11, 2019
@benjamn benjamn self-assigned this Jan 11, 2019
@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented Mar 12, 2019

We're also using nginx, deployed with MUP. Haven't changed any ngnix settings from the MUP defaults.
Response headers on https://www.virtualinout.com/__cordova/manifest.json show cache-control: public, max-age=31536000 but that should be served the same for Android and iOS.

@mozfet

This comment has been minimized.

Copy link

@mozfet mozfet commented Mar 13, 2019

@mozfet np. Looking forward to hear your results of HCP against your prod(-like) environment.

Looks like its working fine in my STAGE environment. Hold thumbs... going to try PROD as soon as Apple approved the app in the App Store.

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Mar 13, 2019

@menelike, removing the cache settings in our nginx solved this problem for us.

@Nauzer, @RealHandy, @benjamn, FYI.

Thanks everyone and cheers!

@menelike

This comment has been minimized.

Copy link

@menelike menelike commented Mar 13, 2019

@rj-david puhh....finally, this was a hard one. Now everyone can be sure that HCP works again.

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented Mar 13, 2019

So what would I need to change in my default MUP nginx config to fix my experience of this same issue?

MUP provides the nginxServerConfig setting but I wouldn't know what to change. @zodern, have you heard of other MUP users having this issue (HCP on iOS only working the 1st time after a fresh app install. Android is fine. Previously experienced by @rj-david and myself above, but resolved for @rj-david by removing nginx config settings)?

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Mar 13, 2019

@wildhart, I took a quick look at MUP and seems like it has a default nginx setting. Since this is being used by a lot of meteor users, the understanding is that it has the correct nginx cache settings (or in this case, there are no cache settings).

Have you seen anything related to what we saw yesterday: #10277 (comment)

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Mar 13, 2019

We're also using nginx, deployed with MUP. Haven't changed any ngnix settings from the MUP defaults.
Response headers on https://www.virtualinout.com/__cordova/manifest.json show cache-control: public, max-age=31536000 but that should be served the same for Android and iOS.

Sorry, I missed this post. This cache setting was the one that was previously causing us problems

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented Mar 13, 2019

I discovered the MUP command mup proxy nginx-config which gave this output: https://pastebin.com/bUcbC0Pz

I can't see anything there about cache except for SSL cache.

Have you seen anything related to what we saw yesterday: #10277 (comment)

I haven't been able to access iOS app logs during an HCP yet, but I'll try.

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Mar 14, 2019

You might want to explicitly add a location block just for manifest with cache control header ignored:
https://www.nginx.com/blog/nginx-caching-guide/

I'm not familiar how to use nginxServerConfig

@Nauzer

This comment has been minimized.

Copy link

@Nauzer Nauzer commented Mar 17, 2019

Workaround

I have not tried (busy on other stuff) this but a way to encode this workaround would be:

codeblock

This should only fire a location.reload() on the first HCP.
Note: this code needs to be on the installed APP.

@brucejo75
Thanks for this tip. Works like a charm for us 👍
Since I noticed that after the first reload the HTML/CSS is still the 'old' version of my app but the React components are actually already on the new version I thought I can make use of that 'feature' and implement as follows:

Created a Meteor method that checks a sent version against the current server version.

reloadRequired: function(buildCode) {
        if (!buildCode || Meteor.settings.public.build > buildCode) {
            console.log('reload required for App with buildcode', buildCode);
            return true;
        } else {
            return false;
        }
    }

From a React component that is already loaded by the first version of my app on my login screen (the first screen of the app) I call this Method in the componentDidMount() lifecycle function.

componentDidMount() {
        if(Meteor.isCordova && 'android' === device.platform.toLowerCase()) {
            Meteor.setTimeout(() => {
                Meteor.call('reloadRequired', Meteor.settings.public.build, (e,result) => {
                    if(!e && result) {
                        location.reload();
                    }
                });
            }, 10000);
        }
    }

Note that the build code already was part of my settings file used to build the initial App Store version of the app. But even if you don't have that implemented yet I believe you can use the above code as long as you have an existing React component - preferably on the first page of your app.

@rj-david

This comment has been minimized.

Copy link

@rj-david rj-david commented Mar 21, 2019

@wildhart, were you able to solve the cache?

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented Mar 21, 2019

No, I haven't been able to play with the nginx cache yet, and I'm on vacation now until April..

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented May 21, 2019

Sorry for the haitus. I've been able to access the iOS logs and confirmed the findings of @rj-david #10277 (comment), that iOS is caching the /__cordova/manifest.json file after the first HCP.

Using MUP I've managed to prevent the cache and finally got HCP working on iOS again. See my MUP bug report/suggestion here: zodern/meteor-up#1086

@KoenLav

This comment has been minimized.

Copy link

@KoenLav KoenLav commented May 23, 2019

@wildhart we seem to have resolved our issue using a similar approach using Cloudflare (setting a Page rule which bypasses the cache for any requestions to .ourdomain.com//manifest.json).

@benjamn I'm guessing it should be possible to set the Cache-Control headers on the side of Meteor, but am not sure where to look; any pointers?

@filipenevola

This comment has been minimized.

Copy link
Member

@filipenevola filipenevola commented May 23, 2019

@KoenLav I'm investigating a new HCP problem on iOS that we are having but I already change the Cache-Control in my Meteor app for static assets like this

WebApp.rawConnectHandlers.use((req, res, next) => {
  if (
    req._parsedUrl.pathname.match(/\.(jpe?g|png|gif|svg|eot|ttf|woff|woff2)$/i)
  ) {
    // one year
    res.setHeader('Cache-Control', `max-age=${OFFLINE_CACHE_EXPIRE}`);
  }
  next();
});
@filipenevola

This comment has been minimized.

Copy link
Member

@filipenevola filipenevola commented May 23, 2019

I added this but my HCP still not working on iOS (Meteor 1.8) but it was working until a few weeks ago, then I guess my problem is different


  if (req._parsedUrl.pathname.match(/manifest\.json$/i)) {
    // https://github.com/zodern/meteor-up/issues/1086
    // no cache for /__cordova/manifest.json
    res.setHeader(
      'Cache-Control',
      'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0'
    );
  }
@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented May 23, 2019

@filipenevola, I'm pretty sure the /__cordova files are not served through the WebApp handlers.

I've confirmed this on localhost by using

WebApp.connectHandlers.use((req, res, next) => {
	console.log(req._parsedUrl.pathname);
	next();
});

And the lack of console messages confirms that the handler is not being called on the /__cordova/manifest.json file.

You can check for yourself: in Chrome navigate direct to your manifest.json file and look at the network tab of Dev Tools. You will only see cache-control: public, max-age=31536000

The extra Cache-Control header needs to be added by the server, unless something can be done at a lower level in Meteor by @benjamn...

@filipenevola

This comment has been minimized.

Copy link
Member

@filipenevola filipenevola commented May 23, 2019

@wildhart I checked this but I got the opposite. I was able to see it affecting the requests on Chrome and also logs in the server.

Are you importing the file with this WebApp.connectHandlers code on server side startup?

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented May 24, 2019

@filipenevola, yes my test WebApp.connectHandlers code is imported into the server bundle. I can see the console messages when I browse to routes in my app but not when I browse to the manifest.js file. Interesting that you do.

So you've confirmed that your server is now sending the manifest with the correct no-store, no-cache header, but iOS still isn't updating the HCP, correct? Have you tried uninstalling the iOS app from the device and reinstalling it? Once an install of the app has cached an old manifest nothing you change on the server will make it get a fresh copy until you delete the app.

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented May 24, 2019

Suggestion for @benjamn: Could it be as simple as adding a cache-busting timestamp to the manifest fetch request, making the app always get a fresh copy no matter what caches/proxies are in the way?

const manifestUrl = manifestUrlPrefix + getItemPathname("/manifest.json");

Change to:

    const manifestUrl = manifestUrlPrefix + getItemPathname("/manifest.json") + '?' + new Date().valueOf();
@filipenevola

This comment has been minimized.

Copy link
Member

@filipenevola filipenevola commented May 24, 2019

@wildhart Yes, I had uninstalled but I don't know why it is not working, we are updating to Meteor 1.8.1 to see if it's working there.

@brucejo75

This comment has been minimized.

Copy link
Contributor

@brucejo75 brucejo75 commented May 24, 2019

@wildhart, did you fork the webapp package and give your fix a try?

It is pretty simple to do without rebuilding all of meteor:

  • clone meteor
  • copy the webapp package into your project
  • make modifications to the package
  • I usually make sure the package is referred to directly in .meteor/packages
  • give it a build and your new code will be used.

Then if it works, copy your fixes back to a PR branch on your meteor clone and submit a pull request.

@filipenevola

This comment has been minimized.

Copy link
Member

@filipenevola filipenevola commented May 27, 2019

@wildhart my HCP are working now and the only change I did was the manifest cache one, I think something was still caching last time I tried and today I'm really cache free.

Just to be clear for future people, my only change was this on server side of my Meteor app

WebApp.rawConnectHandlers.use((req, res, next) => {
  if (req._parsedUrl.pathname.match(/manifest\.json$/i)) {
    // eslint-disable-next-line no-console
    console.log('requesting manifest.json', req._parsedUrl.pathname);
    // https://github.com/zodern/meteor-up/issues/1086
    // no cache for /__cordova/manifest.json
    res.setHeader(
      'Cache-Control',
      'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0'
    );
  }
  next();
});

@KoenLav

This comment has been minimized.

Copy link

@KoenLav KoenLav commented May 27, 2019

@filipenevola this seems like a change that should be integrated into Meteor; could you make a PR?

@benjamn could you confirm?

@filipenevola

This comment has been minimized.

Copy link
Member

@filipenevola filipenevola commented May 27, 2019

@KoenLav sure.

Let's wait for Ben first.

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented May 27, 2019

@filipenevola's, I've discovered why your solution wasn't having any effect for me. You were using WebApp.rawConnectHandlers but I was using WebApp.connectHandlers. When I use the raw version it works fine (on localhost, haven't tried production).

@brucejo75, I haven't tested my suggestion, and unfortunately at the moment I don't really have time to - to test it properly involves spinning up staging servers and compiling apps in xCode all of which is time consuming. Might have time at the weekend... I figured that Ben would know instantly whether it would work or not, or if there are any unintended consequences I'm not aware of.

@wildhart

This comment has been minimized.

Copy link

@wildhart wildhart commented May 27, 2019

I've discovered that my errant cache-control: public, max-age=31536000 header was self-inflicted. I had included is as part of my CDN configuration, in a separate file I found this:

WebApp.rawConnectHandlers.use(function(req, res, next) {
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
    res.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization");
    if (req._parsedUrl.pathname.match(/\.(js|font\.css|css|jpg|png|ttf|ttc|otf|eot|woff|woff2|json)$/)) {
        res.setHeader('cache-control', 'public, max-age=31536000');
    } 
    next();
});

I must've picked that code up from a guide or forum when I first implemented a CDN years ago.

I've now fixed it to this:

WebApp.rawConnectHandlers.use(function(req, res, next) {
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
    res.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization");
    if (req._parsedUrl.pathname.match(/\.json$/)) {
        res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0');
    } else if (req._parsedUrl.pathname.match(/\.(js|font\.css|css|jpg|png|ttf|ttc|otf|eot|woff|woff2)$/)) {
        res.setHeader('cache-control', 'public, max-age=31536000');
    }
    next();
});

So apologies for suggesting that Meteor and/or MUP were inserting this header, it was me all along. Maybe Meteor/MUP don't need to fix anything, or maybe it would be wise for them to add appropariate default 'no-cache' headers anyway...

@derwaldgeist

This comment has been minimized.

Copy link

@derwaldgeist derwaldgeist commented Oct 26, 2019

Is this still open for a year now?

@RealHandy

This comment has been minimized.

Copy link

@RealHandy RealHandy commented Oct 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.