Smarter immutability #192
Description
The assets server has been designed around the concept of immutable assets at its core. When files are uploaded, unique hashes are generated from the file contents, meaning that assets with generated URLs can be considered immutable. E.g.:
https://assets.ubuntu.com/v1/4d7a830e-logo-ubuntuone.png
This is why we serve them with cache-control: max-age=31556926.
However, the assets server also supports serving assets at custom URLs. E.g.:
https://assets.ubuntu.com/v1/vanilla-framework-version-3.6.1.min.css
Although the version number in this case suggests this file is probably not going to change at the same URL, there's nothing to guarantee it. However, we still server these files with the same cache-control: max-age=31556926 header as if it's immutable. This is why we strongly discourage deleting / replacing assets at the same URL.
However it occurs to me that we don't need to be strict in this way. The assets server could happily support both styles of usage - it just needs to have knowledge of whether an asset is considered immutable or not.
Auto-generated URLs with unique hashes in them should always be considered immutable (and should probably also be served with cache-control: immutable), whereas assets with custom URLs should probably be considered to be mutable by default, and so should contain something more like our standard cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300. I think we should probably also provide the option for assets with custom URLs to be declared to be immutable, as their filename might have a different immutability mechanism built in, e.g. the version number above.
Each of these options can then be provided through the manager, but we should make sure we make very clear the performance downside when defining custom URLs, to discourage their use as a standard practice.