rack 1.1.6 → 1.6.9

data/README.rdoc

@@ -0,0 +1,312 @@
+= Rack, a modular Ruby webserver interface {<img src="https://secure.travis-ci.org/rack/rack.svg" alt="Build Status" />}[http://travis-ci.org/rack/rack] {<img src="https://gemnasium.com/rack/rack.svg" alt="Dependency Status" />}[https://gemnasium.com/rack/rack]
+
+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
+* EventedMongrel
+* SwiftipliedMongrel
+* WEBrick
+* FCGI
+* CGI
+* SCGI
+* LiteSpeed
+* Thin
+
+These web servers include Rack handlers in their distributions:
+* Ebb
+* Fuzed
+* Glassfish v3
+* Phusion Passenger (which is mod_rack for Apache and for nginx)
+* Puma
+* Rainbows!
+* Reel
+* Unicorn
+* unixrack
+* uWSGI
+* yahns
+* Zbatery
+
+Any valid Rack app will run the same on all these handlers, without
+changing anything.
+
+== Supported web frameworks
+
+These frameworks include Rack adapters in their distributions:
+* Camping
+* Coset
+* Espresso
+* Halcyon
+* Mack
+* Maveric
+* Merb
+* Racktools::SimpleApplication
+* Ramaze
+* Ruby on Rails
+* Rum
+* Sinatra
+* Sin
+* Vintage
+* Waves
+* Wee
+* ... and many others.
+
+== 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.
+* ...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.
+
+== 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.
+
+== 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.
+
+* https://github.com/rack/rack-contrib
+
+== 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.
+
+== Quick start
+
+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 http://localhost:9292.
+
+== Installing with RubyGems
+
+A Gem of Rack is available at rubygems.org.  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/
+
+== Running the tests
+
+Testing Rack requires the bacon testing framework:
+
+    bundle install --without extra # to be able to run the fast tests
+
+Or:
+
+    bundle install # this assumes that you have installed native extensions!
+
+There are two rake-based test tasks:
+
+    rake test       tests all the fast tests (no Handlers or Adapters)
+    rake fulltest   runs all the tests
+
+The fast testsuite has no dependencies outside of the core Ruby
+installation and bacon.
+
+To run the test suite completely, you need:
+
+  * fcgi
+  * memcache-client
+  * mongrel
+  * thin
+
+The full set of tests test FCGI access with lighttpd (on port
+9203) so you will need lighttpd installed as well as the FCGI
+libraries and the fcgi gem:
+
+Download and install lighttpd:
+
+    http://www.lighttpd.net/download
+
+Installing the FCGI libraries:
+
+    curl -O http://www.fastcgi.com/dist/fcgi-2.4.0.tar.gz
+    tar xzvf fcgi-2.4.0.tar.gz
+    cd fcgi-2.4.0
+    ./configure --prefix=/usr/local
+    make
+    sudo make install
+    cd ..
+
+Installing the Ruby fcgi gem:
+
+    gem install fcgi
+
+Furthermore, to test Memcache sessions, you need memcached (will be
+run on port 11211) and memcache-client installed.
+
+== Configuration
+
+Several parameters can be modified on Rack::Utils to configure Rack behaviour.
+
+e.g:
+
+    Rack::Utils.key_space_limit = 128
+
+=== key_space_limit
+
+The default number of bytes to allow a single parameter key to take up.
+This helps prevent a rogue client from flooding a Request.
+
+Default to 65536 characters (4 kiB in worst case).
+
+=== multipart_part_limit
+
+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.
+
+== History
+
+See <https://github.com/rack/HISTORY.md>.
+
+== Contact
+
+Please post bugs, suggestions and patches to
+the bug tracker at <https://github.com/rack/rack/issues>.
+
+Please post security related bugs and suggestions to the core team at
+<https://groups.google.com/group/rack-core> or rack-core@googlegroups.com. 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
+<https://groups.google.com/group/rack-devel>.
+
+Git repository (send Git patches to the mailing list):
+* https://github.com/rack/rack
+* http://git.vuxu.org/cgi-bin/gitweb.cgi?p=rack-github.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)
+* José Valim (josevalim)
+* Michael Fellinger (manveru)
+* Aaron Patterson (tenderlove)
+* Santiago Pastorino (spastorino)
+* Konstantin Haase (rkh)
+
+and the Rack Alumnis
+
+* 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.
+* 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.
+
+== Copyright
+
+Copyright (C) 2007, 2008, 2009, 2010 Christian Neukirchen <http://purl.org/net/chneukirchen>
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to
+deal in the Software without restriction, including without limitation the
+rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+sell copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+== Links
+
+Rack:: <http://rack.github.io/>
+Official Rack repositories:: <https://github.com/rack>
+Rack Bug Tracking:: <https://github.com/rack/rack/issues>
+rack-devel mailing list:: <https://groups.google.com/group/rack-devel>
+Rack's Rubyforge project:: <http://rubyforge.org/projects/rack>
+
+Christian Neukirchen:: <http://chneukirchen.org/>
+

data/Rakefile

@@ -0,0 +1,124 @@
+# Rakefile for Rack.  -*-ruby-*-
+
+desc "Run all the tests"
+task :default => [:test]
+
+desc "Install gem dependencies"
+task :deps do
+  require 'rubygems'
+  spec = Gem::Specification.load('rack.gemspec')
+  spec.dependencies.each do |dep|
+    reqs = dep.requirements_list
+    reqs = (["-v"] * reqs.size).zip(reqs).flatten
+    # Use system over sh, because we want to ignore errors!
+    system Gem.ruby, "-S", "gem", "install", '--conservative', dep.name, *reqs
+  end
+end
+
+desc "Make an archive as .tar.gz"
+task :dist => %w[chmod ChangeLog SPEC rdoc] do
+  sh "git archive --format=tar --prefix=#{release}/ HEAD^{tree} >#{release}.tar"
+  sh "pax -waf #{release}.tar -s ':^:#{release}/:' SPEC ChangeLog doc rack.gemspec"
+  sh "gzip -f -9 #{release}.tar"
+end
+
+desc "Make an official release"
+task :officialrelease do
+  puts "Official build for #{release}..."
+  sh "rm -rf stage"
+  sh "git clone --shared . stage"
+  sh "cd stage && rake officialrelease_really"
+  sh "mv stage/#{release}.tar.gz stage/#{release}.gem ."
+end
+
+task :officialrelease_really => %w[SPEC dist gem] do
+  sh "shasum #{release}.tar.gz #{release}.gem"
+end
+
+def release
+  "rack-#{File.read("rack.gemspec")[/s.version *= *"(.*?)"/, 1]}"
+end
+
+desc "Make binaries executable"
+task :chmod do
+  Dir["bin/*"].each { |binary| File.chmod(0755, binary) }
+  Dir["test/cgi/test*"].each { |binary| File.chmod(0755, binary) }
+end
+
+desc "Generate a ChangeLog"
+task :changelog => %w[ChangeLog]
+
+file '.git/index'
+file "ChangeLog" => '.git/index' do
+  File.open("ChangeLog", "w") { |out|
+    log = `git log -z`
+    log.force_encoding(Encoding::BINARY) if log.respond_to?(:force_encoding)
+    log.split("\0").map { |chunk|
+      author = chunk[/Author: (.*)/, 1].strip
+      date = chunk[/Date: (.*)/, 1].strip
+      desc, detail = $'.strip.split("\n", 2)
+      detail ||= ""
+      detail = detail.gsub(/.*darcs-hash:.*/, '')
+      detail.rstrip!
+      out.puts "#{date}  #{author}"
+      out.puts "  * #{desc.strip}"
+      out.puts detail  unless detail.empty?
+      out.puts
+    }
+  }
+end
+
+file 'lib/rack/lint.rb'
+desc "Generate Rack Specification"
+file "SPEC" => 'lib/rack/lint.rb' do
+  File.open("SPEC", "wb") { |file|
+    IO.foreach("lib/rack/lint.rb") { |line|
+      if line =~ /## (.*)/
+        file.puts $1
+      end
+    }
+  }
+end
+
+desc "Run all the fast + platform agnostic tests"
+task :test => 'SPEC' do
+  opts     = ENV['TEST'] || '-a'
+  specopts = ENV['TESTOPTS'] ||
+    "-q -t '^(?!Rack::Adapter|Rack::Session::Memcache|Rack::Server|Rack::Handler)'"
+
+  sh "bacon -w -I./lib:./test #{opts} #{specopts}"
+end
+
+desc "Run all the tests we run on CI"
+task :ci => :fulltest
+
+desc "Run all the tests"
+task :fulltest => %w[SPEC chmod] do
+  opts     = ENV['TEST'] || '-a'
+  specopts = ENV['TESTOPTS'] || '-q'
+  sh "bacon -r./test/gemloader -I./lib:./test -w #{opts} #{specopts}"
+end
+
+task :gem => ["SPEC"] do
+  sh "gem build rack.gemspec"
+end
+
+task :doc => :rdoc
+desc "Generate RDoc documentation"
+task :rdoc => %w[ChangeLog SPEC] do
+  sh(*%w{rdoc --line-numbers --main README.rdoc
+              --title 'Rack\ Documentation' --charset utf-8 -U -o doc} +
+              %w{README.rdoc KNOWN-ISSUES SPEC ChangeLog} +
+              `git ls-files lib/\*\*/\*.rb`.strip.split)
+  cp "contrib/rdoc.css", "doc/rdoc.css"
+end
+
+task :pushdoc => %w[rdoc] do
+  sh "rsync -avz doc/ rack.rubyforge.org:/var/www/gforge-projects/rack/doc/"
+end
+
+task :pushsite => %w[pushdoc] do
+  sh "cd site && git gc"
+  sh "rsync -avz site/ rack.rubyforge.org:/var/www/gforge-projects/rack/"
+  sh "cd site && git push"
+end

data/SPEC

@@ -3,7 +3,7 @@ can (and should) use Rack::Lint to enforce it.
 When you develop middleware, be sure to add a Lint before and
 after to catch all mistakes.
 = Rack applications
-A Rack application is an Ruby object (not a class) that
+A Rack application is a Ruby object (not a class) that
 responds to +call+.
 It takes exactly one argument, the *environment*
 and returns an Array of exactly three values:
@@ -11,9 +11,9 @@ The *status*,
 the *headers*,
 and the *body*.
 == The Environment
-The environment must be an true instance of Hash (no
-subclassing allowed) that includes CGI-like headers.
-The application is free to modify the environment.
+The environment must be an instance of Hash that includes
+CGI-like headers.  The application is free to modify the
+environment.
 The environment is required to include these variables
 (adopted from PEP333), except when they'd be empty, but see
 below.
@@ -40,7 +40,17 @@ below.
 <tt>QUERY_STRING</tt>:: The portion of the request URL that
                         follows the <tt>?</tt>, if any. May be
                         empty, but is always required!
-<tt>SERVER_NAME</tt>, <tt>SERVER_PORT</tt>:: When combined with <tt>SCRIPT_NAME</tt> and <tt>PATH_INFO</tt>, these variables can be used to complete the URL. Note, however, that <tt>HTTP_HOST</tt>, if present, should be used in preference to <tt>SERVER_NAME</tt> for reconstructing the request URL.  <tt>SERVER_NAME</tt> and <tt>SERVER_PORT</tt> can never be empty strings, and so are always required.
+<tt>SERVER_NAME</tt>, <tt>SERVER_PORT</tt>::
+                       When combined with <tt>SCRIPT_NAME</tt> and
+                       <tt>PATH_INFO</tt>, these variables can be
+                       used to complete the URL. Note, however,
+                       that <tt>HTTP_HOST</tt>, if present,
+                       should be used in preference to
+                       <tt>SERVER_NAME</tt> for reconstructing
+                       the request URL.
+                       <tt>SERVER_NAME</tt> and <tt>SERVER_PORT</tt>
+                       can never be empty strings, and so
+                       are always required.
 <tt>HTTP_</tt> Variables:: Variables corresponding to the
                            client-supplied HTTP request
                            headers (i.e., variables whose
@@ -49,20 +59,47 @@ below.
                            variables should correspond with
                            the presence or absence of the
                            appropriate HTTP header in the
-                           request.
+                           request. See
+                           <a href="https://tools.ietf.org/html/rfc3875#section-4.1.18">
+                           RFC3875 section 4.1.18</a> for
+                           specific behavior.
 In addition to this, the Rack environment must include these
 Rack-specific variables:
-<tt>rack.version</tt>:: The Array [1,1], representing this version of Rack.
-<tt>rack.url_scheme</tt>:: +http+ or +https+, depending on the request URL.
+<tt>rack.version</tt>:: The Array representing this version of Rack
+                        See Rack::VERSION, that corresponds to
+                        the version of this SPEC.
+<tt>rack.url_scheme</tt>:: +http+ or +https+, depending on the
+                           request URL.
 <tt>rack.input</tt>:: See below, the input stream.
 <tt>rack.errors</tt>:: See below, the error stream.
-<tt>rack.multithread</tt>:: true if the application object may be simultaneously invoked by another thread in the same process, false otherwise.
-<tt>rack.multiprocess</tt>:: true if an equivalent application object may be simultaneously invoked by another process, false otherwise.
-<tt>rack.run_once</tt>:: true if the server expects (but does not guarantee!) that the application will only be invoked this one time during the life of its containing process. Normally, this will only be true for a server based on CGI (or something similar).
+<tt>rack.multithread</tt>:: true if the application object may be
+                            simultaneously invoked by another thread
+                            in the same process, false otherwise.
+<tt>rack.multiprocess</tt>:: true if an equivalent application object
+                             may be simultaneously invoked by another
+                             process, false otherwise.
+<tt>rack.run_once</tt>:: true if the server expects
+                         (but does not guarantee!) that the
+                         application will only be invoked this one
+                         time during the life of its containing
+                         process. Normally, this will only be true
+                         for a server based on CGI
+                         (or something similar).
+<tt>rack.hijack?</tt>:: present and true if the server supports
+                        connection hijacking. See below, hijacking.
+<tt>rack.hijack</tt>:: an object responding to #call that must be
+                       called at least once before using
+                       rack.hijack_io.
+                       It is recommended #call return rack.hijack_io
+                       as well as setting it in env if necessary.
+<tt>rack.hijack_io</tt>:: if rack.hijack? is true, and rack.hijack
+                          has received #call, this will contain
+                          an object resembling an IO. See hijacking.
 Additional environment specifications have approved to
 standardized middleware APIs.  None of these are required to
 be implemented by the server.
-<tt>rack.session</tt>:: A hash like interface for storing request session data.
+<tt>rack.session</tt>:: A hash like interface for storing
+                        request session data.
                         The store must implement:
                         store(key, value)         (aliased as []=);
                         fetch(key, default = nil) (aliased as []);
@@ -75,6 +112,8 @@ be implemented by the server.
                         warn(message, &block)
                         error(message, &block)
                         fatal(message, &block)
+<tt>rack.multipart.buffer_size</tt>:: An Integer hint to the multipart parser as to what chunk size to use for reads and writes.
+<tt>rack.multipart.tempfile_factory</tt>:: An object responding to #call with two arguments, the filename and content_type given for the multipart form field, and returning an IO-like object that responds to #<< and optionally #rewind. This factory will be used to instantiate the tempfile for each multipart form file upload field, rather than the default class of Tempfile.
 The server or the application can store their own data in the
 environment, too.  The keys must contain at least one dot,
 and should be prefixed uniquely.  The prefix <tt>rack.</tt>
@@ -89,6 +128,7 @@ There are the following restrictions:
 * <tt>rack.url_scheme</tt> must either be +http+ or +https+.
 * There must be a valid input stream in <tt>rack.input</tt>.
 * There must be a valid error stream in <tt>rack.errors</tt>.
+* There may be a valid hijack stream in <tt>rack.hijack_io</tt>
 * The <tt>REQUEST_METHOD</tt> must be a valid token.
 * The <tt>SCRIPT_NAME</tt>, if non-empty, must start with <tt>/</tt>
 * The <tt>PATH_INFO</tt>, if non-empty, must start with <tt>/</tt>
@@ -105,15 +145,18 @@ must be opened in binary mode, for Ruby 1.9 compatibility.
 The input stream must respond to +gets+, +each+, +read+ and +rewind+.
 * +gets+ must be called without arguments and return a string,
   or +nil+ on EOF.
-* +read+ behaves like IO#read. Its signature is <tt>read([length, [buffer]])</tt>.
-  If given, +length+ must be an non-negative Integer (>= 0) or +nil+, and +buffer+ must
-  be a String and may not be nil. If +length+ is given and not nil, then this method
-  reads at most +length+ bytes from the input stream. If +length+ is not given or nil,
-  then this method reads all data until EOF.
-  When EOF is reached, this method returns nil if +length+ is given and not nil, or ""
-  if +length+ is not given or is nil.
-  If +buffer+ is given, then the read data will be placed into +buffer+ instead of a
-  newly created String object.
+* +read+ behaves like IO#read.
+  Its signature is <tt>read([length, [buffer]])</tt>.
+  If given, +length+ must be a non-negative Integer (>= 0) or +nil+,
+  and +buffer+ must be a String and may not be nil.
+  If +length+ is given and not nil, then this method reads at most
+  +length+ bytes from the input stream.
+  If +length+ is not given or nil, then this method reads
+  all data until EOF.
+  When EOF is reached, this method returns nil if +length+ is given
+  and not nil, or "" if +length+ is not given or is nil.
+  If +buffer+ is given, then the read data will be placed
+  into +buffer+ instead of a newly created String object.
 * +each+ must be called without arguments and only yield Strings.
 * +rewind+ must be called without arguments. It rewinds the input
   stream back to the beginning. It must not raise Errno::ESPIPE:
@@ -128,35 +171,85 @@ The error stream must respond to +puts+, +write+ and +flush+.
 * +flush+ must be called without arguments and must be called
   in order to make the error appear for sure.
 * +close+ must never be called on the error stream.
+=== Hijacking
+==== Request (before status)
+If rack.hijack? is true then rack.hijack must respond to #call.
+rack.hijack must return the io that will also be assigned (or is
+already present, in rack.hijack_io.
+rack.hijack_io must respond to:
+<tt>read, write, read_nonblock, write_nonblock, flush, close,
+close_read, close_write, closed?</tt>
+The semantics of these IO methods must be a best effort match to
+those of a normal ruby IO or Socket object, using standard
+arguments and raising standard exceptions. Servers are encouraged
+to simply pass on real IO objects, although it is recognized that
+this approach is not directly compatible with SPDY and HTTP 2.0.
+IO provided in rack.hijack_io should preference the
+IO::WaitReadable and IO::WaitWritable APIs wherever supported.
+There is a deliberate lack of full specification around
+rack.hijack_io, as semantics will change from server to server.
+Users are encouraged to utilize this API with a knowledge of their
+server choice, and servers may extend the functionality of
+hijack_io to provide additional features to users. The purpose of
+rack.hijack is for Rack to "get out of the way", as such, Rack only
+provides the minimum of specification and support.
+If rack.hijack? is false, then rack.hijack should not be set.
+If rack.hijack? is false, then rack.hijack_io should not be set.
+==== Response (after headers)
+It is also possible to hijack a response after the status and headers
+have been sent.
+In order to do this, an application may set the special header
+<tt>rack.hijack</tt> to an object that responds to <tt>call</tt>
+accepting an argument that conforms to the <tt>rack.hijack_io</tt>
+protocol.
+After the headers have been sent, and this hijack callback has been
+called, the application is now responsible for the remaining lifecycle
+of the IO. The application is also responsible for maintaining HTTP
+semantics. Of specific note, in almost all cases in the current SPEC,
+applications will have wanted to specify the header Connection:close in
+HTTP/1.1, and not Connection:keep-alive, as there is no protocol for
+returning hijacked sockets to the web server. For that purpose, use the
+body streaming API instead (progressively yielding strings via each).
+Servers must ignore the <tt>body</tt> part of the response tuple when
+the <tt>rack.hijack</tt> response API is in use.
+The special response header <tt>rack.hijack</tt> must only be set
+if the request env has <tt>rack.hijack?</tt> <tt>true</tt>.
+==== Conventions
+* Middleware should not use hijack unless it is handling the whole
+  response.
+* Middleware may wrap the IO object for the response pattern.
+* Middleware should not wrap the IO object for the request pattern. The
+  request pattern is intended to provide the hijacker with "raw tcp".
 == The Response
 === The Status
 This is an HTTP status. When parsed as integer (+to_i+), it must be
 greater than or equal to 100.
 === The Headers
 The header must respond to +each+, and yield values of key and value.
+Special headers starting "rack." are for communicating with the
+server, and must not be sent back to the client.
 The header keys must be Strings.
-The header must not contain a +Status+ key,
-contain keys with <tt>:</tt> or newlines in their name,
-contain keys names that end in <tt>-</tt> or <tt>_</tt>,
-but only contain keys that consist of
-letters, digits, <tt>_</tt> or <tt>-</tt> and start with a letter.
+The header must not contain a +Status+ key.
+The header must conform to RFC7230 token specification, i.e. cannot
+contain non-printable ASCII, DQUOTE or "(),/:;<=>?@[\]{}".
 The values of the header must be Strings,
 consisting of lines (for multiple header values, e.g. multiple
-<tt>Set-Cookie</tt> values) seperated by "\n".
+<tt>Set-Cookie</tt> values) separated by "\\n".
 The lines must not contain characters below 037.
 === The Content-Type
-There must be a <tt>Content-Type</tt>, except when the
-+Status+ is 1xx, 204 or 304, in which case there must be none
-given.
+There must not be a <tt>Content-Type</tt>, when the +Status+ is 1xx,
+204, 205 or 304.
 === The Content-Length
 There must not be a <tt>Content-Length</tt> header when the
-+Status+ is 1xx, 204 or 304.
++Status+ is 1xx, 204, 205 or 304.
 === The Body
 The Body must respond to +each+
 and must only yield String values.
 The Body itself should not be an instance of String, as this will
 break in Ruby 1.9.
-If the Body responds to +close+, it will be called after iteration.
+If the Body responds to +close+, it will be called after iteration. If
+the body is replaced by a middleware after action, the original body
+must be closed first, if it responds to close.
 If the Body responds to +to_path+, it must return a String
 identifying the location of a file whose contents are identical
 to that produced by calling +each+; this may be used by the