From b8a17dd97f7a6972f03f00ea848e7c149c52cab1 Mon Sep 17 00:00:00 2001 From: Martijn Walraven Date: Thu, 7 Jan 2016 13:27:55 +0100 Subject: [PATCH] Serve non-cacheable files with a max-age of 0 instead of a day We previously served non-cacheable files with a max-age of a day. This was done to avoid image flickering on page reload (see #773). As far as I can tell, image flickering still occurs because `location.reload` always forces validation. But switching to `location.replace` means that max-age will actually be respected, and we don't want to cache these assets for a day because then changes would not be visible on reloads. --- packages/webapp/webapp_server.js | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/packages/webapp/webapp_server.js b/packages/webapp/webapp_server.js index 3270230f69..6130237587 100644 --- a/packages/webapp/webapp_server.js +++ b/packages/webapp/webapp_server.js @@ -367,17 +367,9 @@ WebAppInternals.staticFilesMiddleware = function (staticFiles, req, res, next) { // Cacheable files are files that should never change. Typically // named by their hash (eg meteor bundled js and css files). // We cache them ~forever (1yr). - // - // We cache non-cacheable files anyway. This isn't really correct, as users - // can change the files and changes won't propagate immediately. However, if - // we don't cache them, browsers will 'flicker' when rerendering - // images. Eventually we will probably want to rewrite URLs of static assets - // to include a query parameter to bust caches. That way we can both get - // good caching behavior and allow users to change assets without delay. - // https://github.com/meteor/meteor/issues/773 var maxAge = info.cacheable ? 1000 * 60 * 60 * 24 * 365 - : 1000 * 60 * 60 * 24; + : 0; // Set the X-SourceMap header, which current Chrome, FireFox, and Safari // understand. (The SourceMap header is slightly more spec-correct but FF