<img src=“https://rack.github.io/logo.png” width=“400” alt=“rack powers web applications” />

<img src=“https://circleci.com/gh/rack/rack.svg?style=svg” alt=“CircleCI” /> <img src=“https://badge.fury.io/rb/rack.svg” alt=“Gem Version” /> <img src=“https://api.dependabot.com/badges/compatibility_score?dependency-name=rack&package-manager=bundler&version-scheme=semver” alt=“SemVer Stability” /> <img src=“http://inch-ci.org/github/rack/rack.svg?branch=master” alt=“Inline docs” />

Rack provides a minimal, modular, and adaptable interface for developing web applications in Ruby. By wrapping HTTP requests and responses in the simplest way possible, it unifies and distills the API for web servers, web frameworks, and software in between (the so-called middleware) into a single method call.

The exact details of this are described in the Rack specification, which all Rack applications should conform to.

The included handlers connect all kinds of web servers to Rack:

• WEBrick

• FCGI

• CGI

• SCGI

• LiteSpeed

• Thin

These web servers include Rack handlers in their distributions:

• Agoo

• Falcon

• NGINX Unit

• Phusion Passenger (which is mod_rack for Apache and for nginx)

• Puma

• Unicorn

• uWSGI

Any valid Rack app will run the same on all these handlers, without changing anything.

These frameworks include Rack adapters in their distributions:

• Camping

• Coset

• Hanami

• Padrino

• Racktools::SimpleApplication

• Ramaze

• Roda

• Ruby on Rails

• Rum

• Sinatra

• Utopia

• WABuR

• … and many others.

Between the server and the framework, Rack can be customized to your applications needs using middleware, for example:

• Rack::URLMap, to route to multiple applications inside the same process.

• Rack::CommonLogger, for creating Apache-style logfiles.

• Rack::ShowException, for catching unhandled exceptions and presenting them in a nice and helpful way with clickable backtrace.

• Rack::Files, for serving static files.

• …many others!

All these components use the same interface, which is described in detail in the Rack specification. These optional components can be used in any way you wish.

If you want to develop outside of existing frameworks, implement your own ones, or develop middleware, Rack provides many helpers to create Rack applications quickly and without doing the same web stuff all over:

• Rack::Request, which also provides query string parsing and multipart handling.

• Rack::Response, for convenient generation of HTTP replies and cookie handling.

• Rack::MockRequest and Rack::MockResponse for efficient and quick testing of Rack application without real HTTP round-trips.

The plethora of useful middleware created the need for a project that collects fresh Rack middleware. rack-contrib includes a variety of add-on components for Rack and it is easy to contribute new modules.

• github.com/rack/rack-contrib

rackup is a useful tool for running Rack applications, which uses the Rack::Builder DSL to configure middleware and build up applications easily.

rackup automatically figures out the environment it is run in, and runs your application as FastCGI, CGI, or WEBrick—all from the same configuration.

Try the lobster!

Either with the embedded WEBrick starter:

ruby -Ilib lib/rack/lobster.rb

Or with rackup:

bin/rackup -Ilib example/lobster.ru

By default, the lobster is found at localhost:9292.

A Gem of Rack is available at rubygems.org. You can install it with:

gem install rack

Several parameters can be modified on Rack::Utils to configure Rack behaviour.

e.g:

Rack::Utils.key_space_limit = 128

The default number of bytes to allow all parameters keys in a given parameter hash to take up. Does not affect nested parameter hashes, so doesn’t actually prevent an attacker from using more than this many bytes for parameter keys.

Defaults to 65536 characters.

The maximum amount of nesting allowed in parameters. For example, if set to 3, this query string would be allowed:

?a[b][c]=d

but this query string would not be allowed:

?a[b][c][d]=e

Limiting the depth prevents a possible stack overflow when parsing parameters.

Defaults to 100.

The maximum number of parts a request can contain. Accepting too many part can lead to the server running out of file handles.

The default is 128, which means that a single request can’t upload more than 128 files at once.

Set to 0 for no limit.

Can also be set via the RACK_MULTIPART_PART_LIMIT environment variable.

See CHANGELOG.md.

See CONTRIBUTING.md.

Please post bugs, suggestions and patches to the bug tracker at issues.

Please post security related bugs and suggestions to the core team at <groups.google.com/forum/#!forum/rack-core> or [email protected]. This list is not public. Due to wide usage of the library, it is strongly preferred that we manage timing in order to provide viable patches at the time of disclosure. Your assistance in this matter is greatly appreciated.

Mailing list archives are available at <groups.google.com/forum/#!forum/rack-devel>.

Git repository (send Git patches to the mailing list):

• github.com/rack/rack

• git.vuxu.org/cgi-bin/gitweb.cgi?p=rack-github.git

You are also welcome to join the #rack channel on irc.freenode.net.

The Rack Core Team, consisting of

• Aaron Patterson (tenderlove)

• Samuel Williams (ioquatix)

• Jeremy Evans (jeremyevans)

• Eileen Uchitelle (eileencodes)

• Matthew Draper (matthewd)

• Rafael França (rafaelfranca)

and the Rack Alumni

• Ryan Tomayko (rtomayko)

• Scytrin dai Kinthra (scytrin)

• Leah Neukirchen (leahneukirchen)

• James Tucker (raggi)

• Josh Peek (josh)

• José Valim (josevalim)

• Michael Fellinger (manveru)

• Santiago Pastorino (spastorino)

• Konstantin Haase (rkh)

would like to thank:

• Adrian Madrid, for the LiteSpeed handler.

• Christoffer Sawicki, for the first Rails adapter and Rack::Deflater.

• Tim Fletcher, for the HTTP authentication code.

• Luc Heinrich for the Cookie sessions, the static file handler and bugfixes.

• Armin Ronacher, for the logo and racktools.

• Alex Beregszaszi, Alexander Kahn, Anil Wadghule, Aredridel, Ben Alpert, Dan Kubb, Daniel Roethlisberger, Matt Todd, Tom Robinson, Phil Hagelberg, S. Brent Faulkner, Bosko Milekic, Daniel Rodríguez Troitiño, Genki Takiuchi, Geoffrey Grosenbach, Julien Sanchez, Kamal Fariz Mahyuddin, Masayoshi Takahashi, Patrick Aljordm, Mig, Kazuhiro Nishiyama, Jon Bardin, Konstantin Haase, Larry Siden, Matias Korhonen, Sam Ruby, Simon Chiang, Tim Connor, Timur Batyrshin, and Zach Brock for bug fixing and other improvements.

• Eric Wong, Hongli Lai, Jeremy Kemper for their continuous support and API improvements.

• Yehuda Katz and Carl Lerche for refactoring rackup.

• Brian Candler, for Rack::ContentType.

• Graham Batty, for improved handler loading.

• Stephen Bannasch, for bug reports and documentation.

• Gary Wright, for proposing a better Rack::Response interface.

• Jonathan Buch, for improvements regarding Rack::Response.

• Armin Röhrl, for tracking down bugs in the Cookie generator.

• Alexander Kellett for testing the Gem and reviewing the announcement.

• Marcus Rückert, for help with configuring and debugging lighttpd.

• The WSGI team for the well-done and documented work they’ve done and Rack builds up on.

• All bug reporters and patch contributors not mentioned above.

Rack

<rack.github.io/>

Official Rack repositories

<github.com/rack>

Rack Bug Tracking

<github.com/rack/rack/issues>

rack-devel mailing list

<groups.google.com/forum/#!forum/rack-devel>

Rack is released under the MIT License.