ManifestStaticFilesStorage. Actually, I’m really using the
whitenoise, but what I’m wanting to bring up isn’t about the compression.
Once the files are hashed, those become excellent candidates for being cached infinitely, because the contents will not change. This is great. Static files served this way are excellent candidates for running through CDNs as well, because we’re not worried about trying to bust those caches.
Unfortunately, when using the
ManifestStaticFilesStorage, it also stores the original file in the manifest. That path will change contents as the static file it points to changes, so it is not suitable for aggressive caching in general.
What I’d like to be able to do is force that static files are only served via the hashed, stable name that won’t change. This will allow me to trust that there isn’t something out there that is trying to read my static file from the non-hashed filename, and having it changed out from under it during a deployment. It would help me sleep at night, and deploy faster. It would allow me to be confident that a CDN for my static files would always be serving the file I intend it to.
The only static file that I’ve currently thought of really wanting at a stable URL is my favicon. For that one, I actually think I’d prefer to serve that up as a regular view, rather than serving it as a static file that I have a redirect pointing to. It would make it rather more obvious, to me at least, that this is a dynamic URL that changes when I need it to, and needs to be separately considered as far as caching headers.
Is a static files storage that only serves the hashed manifest files a reasonable idea, or are there significant challenges I’ve not considered? Does it exist somewhere, or has there been a discussion on the topic that my searching has not uncovered?