Prevent caching issues

[joachimvh]

Description

Some issues popped up in #1757 which were caused by the util.js being cached in the browser. We should prevent this when updating the contents. Some solutions:

• Just completely disable the browser cache through headers for static files. We could still use ETags for some form of caching, although we currently don't generate these for static files.
• Update the main template that links to util.js to add a query/hash parameter to the link containing a version number so it gets updated after every release. We would need some system in place to not forget doing this. It also has the issue that if the root of the server is a static page, that one might also need to be refreshed after a release.

Related to this: the account pages themselves are currently not sending out cache-related headers. We might want to look into doing something with those as well.

[RubenVerborgh]

• Update the main template that links to util.js to add a query /hash parameter to the link containing a version number so it gets updated after every release.

That's the one!

[joachimvh]

Added query parameters in #1782. This is not a complete solution to this issue though. If that is the solution to go for at the very least we should have a script that updates those value for every new release.

[joachimvh]

Note that we don't want to leak the exact version number. So one solution could be to generate a random hash when first starting a new version, storing it, and using that. Or just generate a new hash every time the server restarts as having one cache miss after a server restart is not a big issue. This would result in different values for worker threads. Alternatively we could store the value to have it be the same for all worker threads but not really a necessity. Having a new value on every restart would also help during development when the file is being changed.

[TallTed]

Note that we don't want to leak the exact version number.

That feels very close to security-through-obscurity, which generally gives a false sense of server security.

I can't think of a good reason to work to avoid "leaking" the version number if it's trivially discoverable through something like an HTML HEAD query ... which I strongly believe it should be, because easy discovery of an exact version number can be vital to troubleshooting, bug analysis, etc., and certainly makes it easier to know when to update a plug-in or other component, such as util.js.

[joachimvh]

That feels very close to security-through-obscurity, which generally gives a false sense of server security.

It's not that the security of the server depends on it, but if we can do it like that without extra hassle we might as well do it like that.

Server administrators can know the version of their server and due to the nature of the server it is always possible to add a small component to expose the version through a header if that is preferred.