Opened 7 years ago
Closed 7 years ago
#29277 closed New feature (wontfix)
Add a bust_browser_cache flag to the static template tag
Reported by: | David Kerkeslager | Owned by: | nobody |
---|---|---|---|
Component: | contrib.staticfiles | Version: | 2.0 |
Severity: | Normal | Keywords: | browser-cache-busting static-files |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The proposal is to add a bust_browser_cache
flag to the static
template tag using a similar syntax to passing context variables to the include
template tag. It would look something like this:
{% static 'css/style.css' with bust_browser_cache=True %}
The flag would default to False
to avoid breaking existing usages of the static
tag.
What flag does is add a cache_hash
get parameter to the URL of the static file, with a hash of the static file. So if the content of css/style.css
looks like:
p { color: magenta; }
The generated URL will look like /static/css/style.css?cache_hash=0756793258f5ea00cda3e445de6bb595
.
If the content of css/style.css
changes to:
p { color: magenta; } p::after { content: "Sorry about this awful color."; }
Then the link would be /static/css/style.css?cache_hash=c3aebd6286841ce8f4d76aa8d3eba487
.
This is not a security feature, so I think it would be best to use MD5 because it is fast.
Instead, the purpose of this is to allow us to serve static files with Cache-Control: immutable
or Cache-Control: max-age=<some large number>
without fear. As long as the content of the file does not change, the URL's cache_hash
will not change, so the browser will use the cached version. But if the content of the static file changes, the cache_hash
parameter will change, causing the browser to request the new version of the file. This gets us the best of both worlds: we maximize usage of browser cache for static files, while never having to worry that our users are seeing stale versions of static files.
It may make sense to store the MD5 hash in Django's cache so that it doesn't get calculated every time.
Change History (4)
comment:1 by , 7 years ago
Description: | modified (diff) |
---|
follow-up: 3 comment:2 by , 7 years ago
Isn't this something that is already implemented through ManifestStaticFilesStorage
and CachedStaticFilesStorage
?
https://docs.djangoproject.com/en/2.0/ref/contrib/staticfiles/#manifeststaticfilesstorage
comment:3 by , 7 years ago
Replying to Simon Charette:
Isn't this something that is already implemented through
ManifestStaticFilesStorage
andCachedStaticFilesStorage
?
https://docs.djangoproject.com/en/2.0/ref/contrib/staticfiles/#manifeststaticfilesstorage
Hm. I wasn't aware of that and it is pretty similar, but doing that globally and continuing to store the old files means that a) we can't turn it on/off for individual files (i.e. the hash time for videos/images probably isn't worth it, as they don't change as much as CSS files) and b) references to old files don't throw any errors, they just fail silently. I think that will handle my use case, though. Thanks for taking the time to respond.
comment:4 by , 7 years ago
Component: | Template system → contrib.staticfiles |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
I can implement this ticket, but I haven't contributed to Django before, and looking at the relevant source code it's going to take me a little while to figure out how to do it. If someone else wants to do it who is more familiar with the codebase, it would probably get done quicker.