Comments on: Scaling Your Frontend: Far-Futures Headers and Template Tags

By: David

David — Wed, 18 Mar 2009 18:10:39 +0000

That’s very interesting tabo. I hadn’t paid very close attention, as it appeared it was working fine. Anyways, you could use the same basic code to do something similar.

By: simon

simon — Mon, 16 Mar 2009 10:40:33 +0000

Check out django-compress. It versions, combines, and minifies your js/css files. I use a patched version to bypass using settings.py (current trunk requires this).

By: Arne Brodowski

Arne Brodowski — Mon, 16 Mar 2009 09:58:27 +0000

Because of the caching-issue tabo mentioned I’m using this approach for quite some time now (docstring is in english):

http://www.django-hosting.de/wiki/MediaFileExpire/

It’s very similar to your solution but it doesn’t append the mtime as a query string. Instead it appends the mtime in the filename just before the fileextension and is used in conjunction with some mod_rewrite rule to strip the mtime before reading the file from disk.

By: tabo

tabo — Mon, 16 Mar 2009 09:19:49 +0000

Are you aware that if you do this, your static files won’t be cached?

http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

By: David

David — Mon, 16 Mar 2009 03:06:31 +0000

Honza you are quite correct about a lot of this. The MEDIA_URL solution would be a very useful way to do it, but it isn’t much different than what this is doing (and I think mediaurl() actually simplifies things).

As for the filesystem access, this is entirely up to what you are doing and how you’re doing it. This is meant to be used as a simple example, but if you have a heavy traffic site you’re probably not serving media from your system so this wouldn’t work. On the off chance you are, you may want to run some kind of in-memory caching mechanism on it (wouldn’t be hard to build).

By: dc

dc — Sun, 15 Mar 2009 05:48:59 +0000

Very useful.. Thanks

By: Honza Kral

Honza Kral — Sun, 15 Mar 2009 04:06:19 +0000

Why go to all this trouble which requires:
– access to the files from your frontend (that should not be in high traffic site)
– a filesystem access for every URL rendered (with hundreds of thousands of files, this gets ugly pretty quickly)
– requires you to use template tag for every single occurence of such URL (no URL’s in static files then)

instead you can just set MEDIA_URL = ’some_url/%s’ % VERSION and have your deployment system handle the directories on the media server (simple symlink is usually enough). Settings.py is just a python file, why not use that and compute the VERSION once and for all.

VERSION can be taken from svn’s revision and/or any arbitrary string (we, for example, take it from the package version that we deploy, same version we use to identify DB schema version and resolve dependencies). Plus your deployment process can go into your static files (js and css) and add the version there so that you won’t have to generate those dynamically.

By: Nick

Nick — Sun, 15 Mar 2009 01:38:15 +0000

I can’t understand reason for that. Testing ?
Changing file means that you’ve updated it’s timestamp. So, next time you’ll have new (non-cached) file delivered to client.

By: David

David — Sun, 15 Mar 2009 01:16:50 +0000

That’s the same thing I wanted to do at first, but then I realized that it didn’t really matter. File modification time is MUCH easier

By: Parand

Parand — Sun, 15 Mar 2009 01:14:21 +0000

Thanks for this, I’ve been meaning to do it forever and this is just the kick in the pants needed to implement it. I was thinking of using the svn version number, but file modification time is even easier.