Fix bug 1223560: Never expire versioned assets

[openjck]

Testing

1. Enable production mode
2. Verify that versioned assets (assets with an MD5 hash in the filename) are served up with an Expires header with a value of one year into the future

[groovecoder]

Sorry, deleted previous comments ...

The existing ExpiresByType config logic seems to already be working for assets in production?

In addition, when I applied this change, I got identical Etag values for the 2 separate .css assets on the home page. Unless it was a bug in fx dev tools.

Do we need this extra apache logic, or can we go without it?

[openjck]

The existing ExpiresByType config logic seems to already be working for assets in production?

Currently, we don't differentiate between versioned and non-versioned assets when setting Expires headers. We give all CSS and JavaScript a value of +1 year. Images get +1 month and fonts get +2 weeks.

After these changes, versioned and non-versioned assets will be treated differently. Non-versioned assets (like /static/img/blueprint.png) will continue to use the Expires values described in the previous paragraph. Versioned assets (like /static/img/blueprint.87f886510d2c.png) will get values of +1 year.

So the values happen to be the same for CSS and JavaScript (we used +1 year for all versioned and non-versioned CSS/JS before these changes and will continue to do so) but versioned images and fonts get much better headers.

In addition, when I applied this change, I got identical Etag values for the 2 separate .css assets on the home page. Unless it was a bug in fx dev tools.

Thanks for paying attention to this. I want to be sure we get this right. The second line of the .htaccess file is FileETag MTime. It looks like that causes the Etag value to reflect the modification time of the file, which would explain why some assets have identical values. I verified that the Etag value of an asset only changes when it's re-built by collectstatic, which in turn only happens when the contents change. So it seems to be working correctly, but I wouldn't mind a second set of eyes.

[jezdez]

I would strongly recommend (especially in preparation for the AWS move that will get rid of Apache) to move us to whitenoise as the means to serve static files in production.

It's smart enough to know when a file that is requested contains a hash in the format as Django/pipeline uses and adds those far future headers automatically (but leaves non-hashed files). Here's the docs for Django integration: http://whitenoise.readthedocs.org/en/latest/django.html

Note, this is a tool that works in conjunction with pipeline and is only targetted at production, not for development.

[groovecoder]

Ah, thanks for the clarification @openjck. I over-looked that this adds the "never expires" headers to versioned images and fonts. That'll be a good improvement.

[groovecoder]

👍 for whitenoise ... as a follow-up, I presume?

[openjck]

I would prefer to do it as a follow-up. I totally agree with using it, but wouldn't want to miss out on using far-futures headers in the meantime if this is ready now.

[jezdez]

Yep, totally not needed to be done in this step! Sorry, should have said that :)