Skip to content
This repository
Fetching contributors…


Cannot retrieve contributors at this time

file 133 lines (126 sloc) 6.944 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132
This specification aims to formalize the Rack protocol. You
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
responds to +call+.
It takes exactly one argument, the *environment*
and returns an Array of exactly three values:
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 is required to include these variables
(adopted from PEP333), except when they'd be empty, but see
<tt>REQUEST_METHOD</tt>:: The HTTP request method, such as
                          "GET" or "POST". This cannot ever
                          be an empty string, and so is
                          always required.
<tt>SCRIPT_NAME</tt>:: The initial portion of the request
                       URL's "path" that corresponds to the
                       application object, so that the
                       application knows its virtual
                       "location". This may be an empty
                       string, if the application corresponds
                       to the "root" of the server.
<tt>PATH_INFO</tt>:: The remainder of the request URL's
                     "path", designating the virtual
                     "location" of the request's target
                     within the application. This may be an
                     empty string, if the request URL targets
                     the application root and does not have a
                     trailing slash.
<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>HTTP_</tt> Variables:: Variables corresponding to the
                           client-supplied HTTP request
                           headers (i.e., variables whose
                           names begin with <tt>HTTP_</tt>). The
                           presence or absence of these
                           variables should correspond with
                           the presence or absence of the
                           appropriate HTTP header in the
In addition to this, the Rack environment must include these
Rack-specific variables:
<tt>rack.version</tt>:: The Array [0,1], representing this version of Rack.
<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).
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>
is reserved for use with the Rack core distribution and must
not be used otherwise.

The environment must not contain the keys
(use the versions without <tt>HTTP_</tt>).
The CGI keys (named without a period) must have String values.

There are the following restrictions:
* <tt>rack.version</tt> must be an array of Integers.
* <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>.
* The <tt>REQUEST_METHOD</tt> must be one of +GET+, +POST+, +PUT+,
* 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>
* The <tt>CONTENT_LENGTH</tt>, if given, must consist of digits only.
* One of <tt>SCRIPT_NAME</tt> or <tt>PATH_INFO</tt> must be
  set. <tt>PATH_INFO</tt> should be <tt>/</tt> if
  <tt>SCRIPT_NAME</tt> is empty.
  <tt>SCRIPT_NAME</tt> never should be <tt>/</tt>, but instead be empty.
=== The Input Stream
The input stream must respond to +gets+, +each+ and +read+.
* +gets+ must be called without arguments and return a string,
  or +nil+ on EOF.
* +read+ must be called without or with one integer argument
  and return a string, or +nil+ on EOF.
* +each+ must be called without arguments and only yield Strings.
* +close+ must never be called on the input stream.
=== The Error Stream
The error stream must respond to +puts+, +write+ and +flush+.
* +puts+ must be called with a single argument that responds to +to_s+.
* +write+ must be called with a single argument that is a String.
* +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.
== The Response
=== The Status
The status, if parsed as integer (+to_i+), must be bigger than 100.
=== The Headers
The header must respond to each, and yield values of key and value.
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 values of the header must respond to #each.
The values passed on #each must be Strings
and not contain characters below 037.
=== The Content-Type
There must be a <tt>Content-Type</tt>, except when the
+Status+ is 204 or 304, in which case there must be none
=== The Body
The Body must respond to #each
and must only yield String values.

If the Body responds to #close, it will be called after iteration.

The Body commonly is an Array of Strings, the application
instance itself, or a File-like object.
== Thanks
Some parts of this specification are adopted from PEP333: Python
Web Server Gateway Interface
v1.0 ( I'd like to thank
everyone involved in that effort.
Something went wrong with that request. Please try again.