Far future expires header when assets are served by Rails

[floehopper]

This isn't a problem right now, but when we switch to Heroku we will no longer have a web server to configure this as we currently do in the "Far Future Expires Header" section of our Apache config.

On Heroku the RAILS_SERVE_STATIC_FILES env var is set to instruct Rails to serve files in the public directory. It is possible to configure the response headers for these files:

In config/environments/production.rb:

config.public_file_server.headers = {
  'Cache-Control' => "public, maxage=#{1.year.to_i}"
}

The implementation is based on this section of the Rails asset pipeline documentation. Using the Cache-Control vs Expires header seems to be the modern approach. The former takes priority over the latter and any date/time we chose for an Expires header in the production config would only ever change when the app was restarted.

However, one problem is that this setting applies to all files in the public directory and we have a separate chunk of Apache config for non-asset-pipeline files. It doesn't feel appropriate to set a far-future expiry on files non-asset-pipeline files, because they are not versioned. This needs some thought!

[floehopper]

Note that earlier this evening I accidentally deployed a branch containing the config.public_file_server.headers change mentioned above for a few hours and so there might be some browsers out there which will be caching non-asset-pipeline files for 1 year. 😢