0

Summary: We updated several JS files for a frontend. These changes include several JS files and a single Minified JS file. These files are served via a Play server. We pushed these changed files (non minified JS and the single minfied JS file) to the Play server.

Problem: The single Minified JS file is not being served to browser sessions.

Steps:

We pushed the changed Minfied JS to the Play Server.

We are able to access the changed minified JS file via a CURL command. This shows that the changed Minfied JS file is available on the Play server

However when any browser requests the file from the Play server, the browser is getting the old Minified JS file instead of the changed Minified JS file.

We know it is not a browser cache issue. (tried via incognito session, or from a previously unused browser & rowser cache flushed)

The issue is

A new minfied JS file is available on the Play server

The new minfied JS file is accessible via a CURL command - proving that the new minfied file is on the server

However, When the a browser requests the UI; the browser is getting the old minfied JS file from the server.

This is obviously bizzare, and very strange.

Techstack

Postgress/ Java/Scala/Play > ALB > Cloudfront

Bypassing CLoudfront does not eliminate the problem. So the problem is not Cloudfront

  • Bypassed cloudfront

  • CURL command on Play server retrieves correct JS file

    1. Push updated minified JS to Play server
    2. Request front-end from any browser
    3. See new front-end
frank f
  • 186
  • 1
  • 4
  • 2
    browsers cache data, have you flushed the cache on the browser? – sferret Jan 03 '19 at 20:15
  • 2
    To specify a reasonable test you can do to check the caching theory: 1. Close Chrome (exit process) 2. Open Chrome again. 3. Open a new Incognito tab in Chrome. (alternatively you can use [Disable Cache from Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/network-performance/)) 4. Open your site. Which JS file is loaded: the new or the old one? If this test shows the new one, then it is most probably a browser caching problem and the typical way to fix it is to use some kind of versioning of your JS files in your links inside HTML as Binu suggests – SergGr Jan 04 '19 at 01:39
  • It’s not on the browser side - affects everyone and across all sessions – frank f Jan 04 '19 at 15:48
  • @frankf, am I right that you did the test I suggested i.e. used a brand new browser session or in some other way bypassed the browser caching and still got the same? The fact that all the _old_ sessions are affected in the same way should not be a surprise because caching strategy should be the same for all the browsers that got this file from the old server. The theory that the Play server distinguishes between a CURL request and a browser request sounds very strange. Chrome DevTools under the Network tab allows Context Menu > Copy > Copy as CURL. Try to eliminate the difference that way. – SergGr Jan 05 '19 at 02:35

1 Answers1

0

You need to add version at the end of javascript link . Eg: /yourjs.js?1234.

Update:

if above solution is not working, you need to create a hash of the content and use this as the cache buster. More info on cache buster can be found here: https://curtistimson.co.uk/post/front-end-dev/what-is-cache-busting/

IMHO, you should use Version instead of timestamp. Because caching CSS and JS will speed up the loading of the web pages. Adding a timestamp, your user will be forced to download files again and again.

Using version, your users will download files only when new version is created.

You can use below code for Versioning.

<script src="yourscript.js?version=1"></script>
Binu
  • 42
  • 6