Rack: HTTP request handling made easy

Posted by Mirko Stocker on Apr 02, 2008

Sections

Development,

Architecture & Design

Topics

Ruby on Rails ,

Web Frameworks ,

Ruby ,

Technology ,

Scripting

Tags

Ruby on Rails ,

Rails

Rack provides an interface between webservers and Ruby web-frameworks. This relieves the framework creators from the burden of writing a handler for each specific webserver and thus removes a lot of duplicated effort.

Working with Rack is really easy. The following example is all you need to create a minimal application handler that runs with Mongrel:

require 'rack'
app = lambda { |env| [200, {"Content-Type" => "text/plain"}, ['Hello World!']] }
Rack::Handler::Mongrel.run(app, :Port => 3000)  

The env argument contains a hash of environment variables and request parameters. The return value of the block consists of an array with three elements: the HTTP status code, the header and the body of the response.

Christian Neukirchen, the creator of Rack, shared some information about the history of Rack with InfoQ:

In the beginning, I was dissatisfied with the state of web frameworks in Ruby, and threw around a few ideas on writing my own. Along that line, web.py was released, and I liked how small and easy they kept it. So I started writing the framework but I got nowhere, because I was side tracked writing the usual stuff like Cookie parsing and so on. I actually copied a few bits of code from other projects, but it was still pretty boring work that just had to be done. That framework never got far.

Later, I learned about Python's Nevow, and wanted to implement something akin to it, but as soon as I started, I noticed I kept rewriting all these helpers and adapters for different servers. Learning more about Python frameworks, I stumbled upon WSGI, read, liked, simplified, and finally drafted Rack. I reassembled the code I already had written, modularized it based on the structure of Python Paste, and soon Rack 0.1 was ready.

When Rack was usable, I still didn't have a framework I liked, so I implemented Coset, which is what I use these days. It draws inspiration from Camping, web.py and RESTlet.

There's already quite an impressive list of frameworks with support for Rack:

* Camping (included in the Rack distribution)
* Coset
* Halcyon
* Maveric
* Merb
* Mack
* Racktools::SimpleApplication
* Ramaze
* Rails (third party, delivered with thin)
* Sinatra
* Vintage

Rack can also be used collaboratively with a framework. So for example, if one just needs simple and fast processing for certain requests, Rack's Rack::Cascade can be used to cascade several applications. This blog post by Ezra Zygmuntowicz explains how to use Rack for file uploads without going through the full merb stack.

For the future, Christian plans to stabilize the specification for a 1.0 release.

To learn more about Rack, visit the official Rack website. For more in-depth information, there's a paper from Euruko 07 about the inner workings of Rack.

1. Back to top

   Great Rack!

   by Levi Cook

   FWIW; I'm a long time python programmer that never fully grokked WSGI and Paste. Some how Rack's simplest application example sparked an "aha!" that just wasn't there before. I'll have to revisit the python contingent to see what I overlooked.
   
   One question..can you pass an IO object back for the response body?

   Reply

2. Back to top

   Re: Great Rack!

   by Mirko Stocker

   One question..can you pass an IO object back for the response body?

   
   
   I've just tried it and yes, it seems to work :)

   Reply

• Older >