# Rack 1.0, a modular Ruby webserver interface **URL:** \ **Category:** Ruby\ **Created:** [April 25, 2009, 3:41pm UTC](https://www.ruby-forum.com/t/rack-1-0-a-modular-ruby-webserver-interface/166456 "2009-04-25T15:41:06Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![cneuhaus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/34f0e0/32.png) [@cneuhaus](https://www.ruby-forum.com/u/cneuhaus)\ **Post date:** [April 25, 2009, 3:41pm UTC](https://www.ruby-forum.com/t/rack-1-0-a-modular-ruby-webserver-interface/166456/1 "2009-04-25T15:41:06Z")
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](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. - [GitHub - rack/rack-contrib: Contributed Rack Middleware and Utilities](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:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid). Mailing list archives are available at [http://groups.google.com/group/rack-devel](http://groups.google.com/group/rack-devel). There is a bug tracker at [http://rack.lighthouseapp.com/](http://rack.lighthouseapp.com/). Git repository (send Git patches to the mailing list): - [GitHub - rack/rack: A modular Ruby web server interface.](http://github.com/rack/rack) - [http://git.vuxu.org/cgi-bin/gitweb.cgi?p=rack.git](http://git.vuxu.org/cgi-bin/gitweb.cgi?p=rack.git) You are also welcome to join the #rack channel on [irc.freenode.net](http://irc.freenode.net). == Thanks The Rack Core Team, consisting of - Christian N. (chneukirchen) - James T. (raggi) - Josh P. (josh) - Michael F. (manveru) - Ryan T. (rtomayko) - Scytrin dai Kinthra (scytrin) would like to thank: - Adrian M., for the LiteSpeed handler. - Christoffer S., for the first Rails adapter and Rack::Deflater. - Tim F., for the HTTP authentication code. - Luc H. for the Cookie sessions, the static file handler and bugfixes. - Armin Ronacher, for the logo and racktools. - Aredridel, Ben A., Dan K., Daniel Roethlisberger, Matt T., Tom R., Phil H., and S. Brent Faulkner for bug fixing and other improvements. - Brian C., for Rack::ContentType. - Graham Batty, for improved handler loading. - Stephen B., for bug reports and documentation. - Gary W., for proposing a better Rack::Response interface. - Jonathan B., 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 N. [http://purl.org/net/chneukirchen](http://purl.org/net/chneukirchen) Rack is freely distributable under the terms of an MIT-style license. == Links Rack:: [http://rack.rubyforge.org/](http://rack.rubyforge.org/) Rack’s Rubyforge project:: [http://rubyforge.org/projects/rack](http://rubyforge.org/projects/rack) Official Rack repositories:: [http://github.com/rack](http://github.com/rack) rack-devel mailing list:: [http://groups.google.com/group/rack-devel](http://groups.google.com/group/rack-devel) Happy hacking and have a nice day, Christian N. on behalf of the Rack Core Team. 571dc1d6a74a2a4cb0082a59612ff8b2f80f8752 rack-1.0.0.gem 53609db88608fb846a0a62df803ae2bb33372cfe rack-1.0.0.tar.gz ---
**Author:** ![cneuhaus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/34f0e0/32.png) [@cneuhaus](https://www.ruby-forum.com/u/cneuhaus)\ **Post date:** [April 25, 2009, 4:50pm UTC](https://www.ruby-forum.com/t/rack-1-0-a-modular-ruby-webserver-interface/166456/2 "2009-04-25T16:50:12Z")
Christian N. wrote: > - rack.input must be rewindable and support reading into a buffer, > wrap with Rack::RewindableInput if it isn’t. Nick S. 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 ---
**Author:** ![cneuhaus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/34f0e0/32.png) [@cneuhaus](https://www.ruby-forum.com/u/cneuhaus)\ **Post date:** [April 25, 2009, 8:08pm UTC](https://www.ruby-forum.com/t/rack-1-0-a-modular-ruby-webserver-interface/166456/3 "2009-04-25T20:08:36Z")
Christian N. 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 B. [www.jamesbritt.com](http://www.jamesbritt.com) - Playing with Better Toys [www.ruby-doc.org](http://www.ruby-doc.org) - Ruby Help & Documentation [www.rubystuff.com](http://www.rubystuff.com) - The Ruby Store for Ruby Stuff ---
**Author:** ![cneuhaus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/34f0e0/32.png) [@cneuhaus](https://www.ruby-forum.com/u/cneuhaus)\ **Post date:** [April 25, 2009, 10:54pm UTC](https://www.ruby-forum.com/t/rack-1-0-a-modular-ruby-webserver-interface/166456/4 "2009-04-25T22:54:15Z")
Charles Oliver N. wrote: > 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 ---
**Author:** ![cneuhaus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/34f0e0/32.png) [@cneuhaus](https://www.ruby-forum.com/u/cneuhaus)\ **Post date:** [April 26, 2009, 11:01am UTC](https://www.ruby-forum.com/t/rack-1-0-a-modular-ruby-webserver-interface/166456/5 "2009-04-26T11:01:34Z")
On Sat, Apr 25, 2009 at 7:10 PM, Christian N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hello, > > Today we are proud to release Rack 1.0, which was close to almost be > codenamed MiddleWarem4Ever. Congrats on the 1.0 release 🙂 martin