Rack 0.2, a modular Ruby webserver interface

Hello,

Today I’m proud to release Rack 0.2.

= Rack, a modular Ruby webserver interface

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.

== Supported web servers

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

  • Mongrel
  • Mongrel/Swiftcore (require it before Rack.)
  • WEBrick
  • FCGI
  • CGI

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

== Supported web frameworks

The included adapters connect Rack with existing Ruby web frameworks:

  • Camping

These frameworks include Rack adapters in their distributions:

  • Ramaze
  • Maveric
  • Racktools::SimpleApplication

== Available middleware

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::File, for serving static files.

All these components use the same interface, which is described in
detail in the Rack specification. You can choose to use them exactly
in the way you want.

== Convenience

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.

== rackup

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 standalone with Mongrel or
WEBrick—all from the same configuration.

== Where can I get it?

You can download Rack 0.2 at

    http://chneukirchen.org/releases/rack-0.2.0.tar.gz
              http://rubyforge.org/projects/rack

Alternatively, you can checkout from the development repository with:

       darcs get http://chneukirchen.org/repos/rack

(Patches using “darcs send” are most welcome.)

== Installing with RubyGems

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

gem install rack

I also provide a local mirror of the gems (and development snapshots)
at my site:

gem install rack --source http://chneukirchen.org/releases/gems

== History

  • March 3rd, 2007: First public release 0.1.

  • May 16th, 2007: Second public release 0.2.

    • HTTP Basic authentication.
    • Cookie Sessions.
    • Static file handler.
    • Improved Rack::Request.
    • Improved Rack::Response.
    • Added Rack::ShowStatus, for better default error messages.
    • Bug fixes in the Camping adapter.
    • Removed Rails adapter, was too alpha.

== Contact

Please mail bugs, suggestions and patches to
mailto:[email protected].

Darcs repository (“darcs send” is welcome for patches):
http://chneukirchen.org/repos/rack

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

== Thanks to

  • Michael F., for the helpful discussion, bugfixes and a better
    Rack::Request interface.
  • Christoffer S., for the Rails adapter.
  • Tim F., for the HTTP authentication code.
  • Armin Ronacher, for the logo and racktools.
  • Aredridel, for bug fixing.
  • Gary W., for proposing a better Rack::Response interface.
  • Alexander Kellett for testing the Gem and reviewing the announce.
  • 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.

== Copyright

Copyright (C) 2007 Christian N.
http://purl.org/net/chneukirchen

Rack is freely distributable under the terms of an MIT-style license.

== Links

Rack:: http://rack.rubyforge.org/
Rack’s Rubyforge project:: http://rubyforge.org/projects/rack

Camping:: http://camping.rubyforge.org/
Ramaze:: http://ramaze.rubyforge.org/
Maveric:: http://maveric.rubyforge.org/
racktools:: http://lucumr.pocoo.org/trac/repos/racktools/

Christian N.:: http://chneukirchen.org/

Happy hacking and have a nice day,
Christian N.

f1063711f228d19875a3211d71308b5c rack-0.2.0.tar.gz
fad21b5fac8790fe6bf295fefdac5816 rack-0.2.0.gem

Hi Christian,

On 16-May-07, at 11:20 AM, Christian N. wrote:

servers, web frameworks, and software in between (the so-called
middleware) into a single method call.

[snip]

  • 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.

Does this mean that, using Rack, I can make my own request/response
objects up and push them into the web framework? That would be very
very good.

What about Merb? Have you discussed this with Ezra yet?

Cheers,
Bob


Bob H. – tumblelog at <http://
www.recursive.ca/so/>
Recursive Design Inc. – weblog at <http://www.recursive.ca/
hutch>
– works at http://www.recursive.ca/

Bob H. [email protected] writes:

Rack provides a minimal, modular and adaptable interface for
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.

Does this mean that, using Rack, I can make my own request/response
objects up and push them into the web framework? That would be very
very good.

Exactly.

What about Merb? Have you discussed this with Ezra yet?

We talked some time ago, and he was interested in it. Haven’t heard
of him since, though.