Forum: Ruby Rack 1.0, a modular Ruby webserver interface

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Christian N. (Guest)
on 2009-04-25 17:41
(Received via mailing list)
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:removed_email_address@domain.invalid>.

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

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 N.
on behalf of the Rack Core Team.

571dc1d6a74a2a4cb0082a59612ff8b2f80f8752  rack-1.0.0.gem
53609db88608fb846a0a62df803ae2bb33372cfe  rack-1.0.0.tar.gz
Charles Oliver N. (Guest)
on 2009-04-25 18:50
(Received via mailing list)
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
James B. (Guest)
on 2009-04-25 22:08
(Received via mailing list)
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           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff
Charles Oliver N. (Guest)
on 2009-04-26 00:54
(Received via mailing list)
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
Martin DeMello (Guest)
on 2009-04-26 13:01
(Received via mailing list)
On Sat, Apr 25, 2009 at 7:10 PM, Christian N.
<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
This topic is locked and can not be replied to.