The new Fingerprinting technique in Rails 3.1

In the new rails 3.1, I heard about the new fingerprinting technique used by them.Looking at the concept I mist say that its hats off the the core team for developing such a great concept.

Here is a quick but thorough overview :

Fingerprinting is a technique whereby the filenames of content that is static or infrequently updated is altered to be unique to the content contained in the file.

When a filename is unique and based on its content, HTTP headers can be set to encourage caches everywhere (at ISPs, in browsers) to keep their own copy of the content. When the content is updated, the fingerprint will change and the remote clients will request the new file. This is generally known as cachebusting.

The most effective technique is to insert a hash of the content into the name, usually at the end. For example a CSS file global.css is hashed and the filename is updated to incorporate the hash.

global.css => global-908e25f4bf641868d8683022a5b62f54.css

This is the strategy adopted by the Rails asset pipeline.

Rails’ old strategy was to append a query string to every asset linked with a built-in helper. In the source the generated code looked like this:



This has several disadvantages:

  1. Not all caches will cache content with a query string
    Steve Souders recommends, “…avoiding a querystring for cacheable resources”. He found that in these case 5-20% of requests will not be cached.
  2. The file name can change between nodes in multi-server environments.
    The query string in Rails is based on the modification time of the files. When assets are deployed to a cluster, there is no guarantee that the timestamps will be the same, resulting in different values being used depending on which server handles the request.

The other problem is that when static assets are deployed with each new release of code, the mtime of all these files changes, forcing all remote clients to fetch them again, even when the content of those assets has not changed.

Fingerprinting avoids all these problems by ensuring filenames are consistent based on their content.

Fingerprinting is enabled by default for production and disabled for all the others environments. You can enable or disable it in your configuration through the config.assets.digest option.


What are sprockets ?

I was looking at the new rails 3.1 release and I frequently came across the term sprockets

This is what it means:

Sprockets is a Ruby library that preprocesses and concatenates JavaScript source files. It takes any number of source files and preprocesses them line-by-line in order to build a single concatenation. Specially formatted lines act as directives to the Sprockets preprocessor, telling it to require the contents of another file or library first or to provide a set of asset files (such as images or stylesheets) to the document root. Sprockets attempts to fulfill required dependencies by searching a set of directories called the load path.

It helps you turn messy JavaScript into clean modules for development and a single .js file for deployment.

Here are some of the benefits of Sprockets:

Extract reusable code and share it across multiple web sites or applications. Sprockets makes it easy to extract JavaScript plugins from your site or application and share them across your portfolio. Use your SCM to check out plugin repositories directly into your site or application. Then tell Sprockets to add the plugins to your load path. Support for asset provisioning lets you bundle CSS and images with JavaScript plugins, too.

Speed up your site by automatically concatenating JavaScript into a single file for production. Concatenating your site’s JavaScript means all your source code is cached in the browser on the first hit. It also means you reduce the number of HTTP requests necessary to load a single page. When combined with gzip compression on the web server, concatenation is the fastest way to serve JavaScript to your users.

Organize your JavaScript source code into multiple commented files and directories. Finally, an end to navigating long, difficult-to-maintain JavaScript source files. With Sprockets, JavaScript source code can live anywhere on your system, even outside your site’s or application’s document root. You’re free to split source code up into multiple files and organize those files into directories during development. You can also add as many comments as you want—they’ll be stripped from the resulting output.

Use bleeding-edge framework and library code in your application. If you use and contribute to open-source JavaScript frameworks and libraries that use Sprockets, like Prototype and, the build processes for those scripts can be integrated directly into your application. That makes it possible to track the latest development versions of your framework and library dependencies by adding their repositories to your application’s Sprockets load path.

Sprockets is compatible with the PDoc JavaScript documentation system and the JavaScript framework of your choice. If you document your JavaScript source code with PDoc, Sprockets will automatically strip documentation comments from the resulting concatenated output. You can use any JavaScript framework you like in your site or application—Sprockets is framework-agnostic.