[ANN] Rack 1.0, a modular Ruby webserver interface

Hello,

Today we are proud to release Rack 1.0, which was close to almost be
codenamed MiddleWarem4Ever.

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

== Specification changes in this release

With Rack 1.0, the Rack specification (found in SPEC) changed in the
following backward-incompatible ways. This was done to properly
support Ruby 1.9 and to deprecate some problematic techniques:

* Rack::VERSION has been pushed to [1,0].
* Header values must be Strings now, split on "\n".
* rack.input must be rewindable and support reading into a buffer,
  wrap with Rack::RewindableInput if it isn't.
* Content-Length can be missing, in this case chunked transfer
  encoding is used.
* Bodies can now additionally respond to #to_path with a filename to
  be served.
* String bodies are deprecated and will not work with Ruby 1.9, use an
  Array with a single String instead.
* rack.session is now specified.

Use Rack::Lint to find out in which ways this possibly broke your
applications and middleware.

== Changes

* April 25th, 2009: Seventh public release 1.0.0.
  * SPEC changes, see above.
  * New middleware Rack::Lock.
  * New middleware Rack::ContentType.
  * Rack::Reloader has been rewritten.
  * Major update to Rack::Auth::OpenID.
  * Support for nested parameter parsing in Rack::Response.
  * Support for redirects in Rack::Response.
  * HttpOnly cookie support in Rack::Response.
  * The Rakefile has been rewritten.
  * Many bugfixes and small improvements.

== Where can I get it?

You can download Rack 1.0 at

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

Alternatively, you can checkout from the development repository with:

    git clone git://github.com/rack/rack.git
    cd rack && git checkout rack-1.0 # for this release

== Supported web servers

The included *handlers* connect all kinds of web servers to Rack:
* Mongrel
* EventedMongrel
* SwiftipliedMongrel
* WEBrick
* FCGI
* CGI
* SCGI
* LiteSpeed
* Thin

These web servers include Rack handlers in their distributions:
* Ebb
* Fuzed
* Phusion Passenger (which is mod_rack for Apache and for nginx)
* Unicorn

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:
* Camping
* Coset
* Halcyon
* Mack
* Maveric
* Merb
* Racktools::SimpleApplication
* Ramaze
* Ruby on Rails
* Rum
* Sinatra
* Sin
* Vintage
* Waves
* Wee

Current links to these projects can be found at
http://wiki.ramaze.net/Home#other-frameworks

== rack-contrib

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.

* http://github.com/rack/rack-contrib

== 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/

== Contact

Please mail bugs, suggestions and patches to
<mailto:rack-devel@googlegroups.com>.

Mailing list archives are available at
<http://groups.google.com/group/rack-devel>.

There is a bug tracker at <http://rack.lighthouseapp.com/>.

Git repository (send Git patches to the mailing list):
* http://github.com/rack/rack
* http://git.vuxu.org/cgi-bin/gitweb.cgi?p=rack.git

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

== Thanks

The Rack Core Team, consisting of

* Christian Neukirchen (chneukirchen)
* James Tucker (raggi)
* Josh Peek (josh)
* Michael Fellinger (manveru)
* Ryan Tomayko (rtomayko)
* Scytrin dai Kinthra (scytrin)

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.
* Aredridel, Ben Alpert, Dan Kubb, Daniel Roethlisberger, Matt Todd,
  Tom Robinson, Phil Hagelberg, and S. Brent Faulkner for bug fixing
  and other improvements.
* 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 contributers not mentioned above.

== Copyright

Copyright (C) 2007, 2008, 2009 Christian Neukirchen <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>
Official Rack repositories:: <http://github.com/rack>
rack-devel mailing list:: <http://groups.google.com/group/rack-devel>

Happy hacking and have a nice day,
Christian Neukirchen
on behalf of the Rack Core Team.

571dc1d6a74a2a4cb0082a59612ff8b2f80f8752 rack-1.0.0.gem
53609db88608fb846a0a62df803ae2bb33372cfe rack-1.0.0.tar.gz

Christian Neukirchen wrote:

* rack.input must be rewindable and support reading into a buffer,
  wrap with Rack::RewindableInput if it isn't.

Nick Sieger pointed me to your implementation of RewindableInput, and I think you should know that Tempfile is a pretty slow API, especially if you're spinning up a tempfile for every incoming request. You'd probably be better off having the default RewindableInput buffer in memory, with a separate option to buffer to a tempfile or similar.

I'm also curious: why was this requirement was added at all? It means all servers will have to buffer request streams, which will often impact performance (since it will have to be buffered either in memory on on disk), and it doesn't seem typical when looking at other service APIs.

- Charlie

Christian Neukirchen wrote:

Hello,

Today we are proud to release Rack 1.0, which was close to almost be
codenamed MiddleWarem4Ever.

= Rack, a modular Ruby webserver interface

Rack should be code-named Shaft, because it's a *bad* mutha ...

    SHUT YOUR MOUTH!

I'm talkin' 'bout Rack ...

    THEN WE CAN DIG IT!

Thanks to chris2 and team: nice Rack!

···

--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

Congrats on the 1.0 release :slight_smile:

martin

···

On Sat, Apr 25, 2009 at 7:10 PM, Christian Neukirchen <chneukirchen@gmail.com> wrote:

Hello,

Today we are proud to release Rack 1.0, which was close to almost be
codenamed MiddleWarem4Ever.

Charles Oliver Nutter wrote:

Christian Neukirchen wrote:

* rack.input must be rewindable and support reading into a buffer,
  wrap with Rack::RewindableInput if it isn't.

Nick Sieger pointed me to your implementation of RewindableInput, and I think you should know that Tempfile is a pretty slow API, especially if you're spinning up a tempfile for every incoming request. You'd probably be better off having the default RewindableInput buffer in memory, with a separate option to buffer to a tempfile or similar.

I'm also curious: why was this requirement was added at all? It means all servers will have to buffer request streams, which will often impact performance (since it will have to be buffered either in memory on on disk), and it doesn't seem typical when looking at other service APIs.

FWIW, I was pointed to the discussion about middleware, which explains some of this. We're in the process of investigating how other http service APIs handle this, and so far they seem to be a little vague on caching/buffering policies.

- Charlie