Prevent caching of static resources

[adiherzog]

HTML templates ("partials") stick in the cache each time after updating to a new Scenarioo version. Only clearing the entire browser cache helps. This is very annoying and for the demo deployments it means that you might not see the latest features even if they are deployed.

Therefore I propose to add a query string to all templates. We could use the Git revision as a parameter (?rev=1234xyz). Any other ideas?

I got the query idea from here: https://groups.google.com/forum/#!msg/angular/wMRtJZ7R480/5bFH_ZhgdRwJ

Tasks

• Is ETAG a valid option, also supported by IE 10 and newer?
• What config options does Tomcat support?
• Is a ServletFilter an option?
• How do other web apps do this (e.g. Outlook Web App)?
• What is AngularJS best practice?

[bruderol]

let's discuss if there is no better solution, otherwise I think this is okay.

[adiherzog]

You're right 😃 Probably ETag is the way to go for static resources like HTML templates.

[bruderol]

yes, that's what I meant. I am quite sure that this is the way we should go. ETag 👍
AND ... We should also use that for REST requests :-)

[danielsuter]

+1

[bruderol]

even if this sounds unsexy ... this is important (in IE we currently have a caching problem), and we could learn a lot about http caching and ETag, etc. when addressing this properly (not only for templates, but also for REST requests when loading data).

Therefore proposing it as a topic for Coding Days.

[adiherzog]

Yeah, that's an important topic. It's not only an issue in IE but also in Google Chrome.

[bruderol]

@adiherzog @danielsuter
I put this to prio 1 and ready. I think we should solve this on coding days, since it is a "show stoper" on every release. We allways get feedback that the new features do not work as expected or even advertised (because they still have the old templates in the browser cache), and I do not want to answer the same questions about the same problems all the times.

[bruderol]

Please take care in the implementation that we have probably the same problems with js-resources and other resources (CSS, ...).

[mi-we]

My conclusions so far:
The Tomcat instance/or the proxy before it that is running the Scenarioo demo is not returning an ETag header for the HTML files as it seems. I deployed the WAR file locally on the Dev VM and there an ETag is returned also for the HTML files. I will try to test this somehow, if it makes a difference.

An interesting approach to the problem of browser caching templates is the one mentioned in the post here:
http://stackoverflow.com/a/27649323

It is possible to have a task during build time which encapsulates all the templates in a single JS file which loads them into the Angular $templateCache. This will also increase the performance of the app, as the templates are not loaded lazily anymore.

[mi-we]

Tested locally now on Firefox. I modified one of the templates a bit and redeployed the WAR file. Because there was a different ETag now for that file, the file was correctly requested again, the others were still cached.

[mi-we]

https://www.npmjs.com/package/gulp-inline-angular-templates

This gulp plugin would take all the templates and inline them in the index.html file for example

[mi-we]

According to different sources including this one: http://stackoverflow.com/questions/31125888/nginx-missing-etag-when-gzip-is-used NGINX before version 1.7.3 purposefully removesx the ETag when the response is compressed with GZip. I have yet to check if this is true for all the cases, the response for index.html for example contains an ETag when requested, but not the template files.

I will try out the Gulp plugin mentioned above to see if it would be easy to integrate in our build chain.

Update: It is true, the index.html, navigation.html and the other JS and CSS resources are missing the "Content-Encoding: "gzip"" header in the response.

[mi-we]

I made a PoC where the templates get inlined in a separate JS file "templates.js". Because this step happens while gulp build, the JS file has to be minified separately so it is at the moment not part of the sources.js like all the other Scenarioo code.

Also there still is an issue where the application info popup does not show up on first visit. I have not yet figured out why.

[mi-we]

Together with @adiherzog the problem with the info popup could be solved, thanks!

[mi-we]

Reopen, there are problems when building the project on a fresh base locally. This has to be solved first.

[bruderol]

@mi-we @adiherzog Thank you sooo much for fixing this! I think and hope the next release will be painless thanks to this!