Using ETags (or the new declarative ETags) in Rails? Are you banging your head on the table over old HTML/CSS/JavaScript still showing even after you deploy? We are proud to release Ettu, a rubygem to smarten up your ETags and save your precious table from further abuse.

Wait you say, what are ETags? As the name implies, they are a way to tag a resource for later identification. Imagine a visitor browses your homepage, and you dutifully fulfil the request. But before you send the page off, you tag it with a unique ETag header. Now, when the visitor visits your homepage again they send that ETag (as an If-None-Match header... go figure) to your server. From there, you compare your homepage's current ETag to the one they sent. Do they not match? Ok, send the page again with the new ETag. The magic happens when they do match, allowing you to skip sending the (kilobytes of) page data and instead just return a 304 Not Modified status code. Bandwidth savings and a speed bump in a nice pretty bow.

Rails takes advantage of ETags using the fresh_when controller method (or it's control flow brother stale?). In the show action of the UsersController? fresh_when @user will compare ETags against that users cache_key, a method that returns a unique string for an Active Record object. If they match, Rails will stop the expensive rendering and return that pretty 304 status code.

But then why are developers stress testing tables with their heads? That's due to Rails' nasty little gotcha, fresh_when doesn't even consider changes to the view code. Do you clear out your old assets when deploying? If you changed anything in your CSS/JavaScript, your visitors are trying to pull down assets that don't exist anymore, all because your ETags are telling them the page is the same (and thus using the same assets).

That's why we are releasing the Ettu gem, Latin for 'And compute you, too?'. Ettu transparently adds your view templates, JavaScript, and CSS files into the ETag equation, giving you peace of mind that your ETags will always be up to date with your current deployment. And it does all this while allowing you to use the same fresh_when syntax you're already used to. So keep doing what you're doing, and let Ettu worry about your view code.