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 David Kerkeslager)

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 David Kerkeslager, 7 years ago

Description: modified (diff)

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.

comment:2 by Simon Charette, 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

in reply to:  2 comment:3 by David Kerkeslager, 7 years ago

Replying to Simon Charette:

Isn't this something that is already implemented through ManifestStaticFilesStorage and CachedStaticFilesStorage?

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 Tim Graham, 7 years ago

Component: Template systemcontrib.staticfiles
Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top