SPEC.rdoc

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 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: The status, the headers, and the body.

The Environment¶ ↑

The environment must be an unfrozen 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.

REQUEST_METHOD

The HTTP request method, such as “GET” or “POST”. This cannot ever be an empty string, and so is always required.

SCRIPT_NAME

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.

PATH_INFO

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. This value may be percent-encoded when originating from a URL.

QUERY_STRING

The portion of the request URL that follows the ?, if any. May be empty, but is always required!

SERVER_NAME

When combined with SCRIPT_NAME and PATH_INFO, these variables can be used to complete the URL. Note, however, that HTTP_HOST, if present, should be used in preference to SERVER_NAME for reconstructing the request URL. SERVER_NAME can never be an empty string, and so is always required.

SERVER_PORT

An optional Integer which is the port the server is running on. Should be specified if the server is running on a non-standard port.

HTTP_ Variables

Variables corresponding to the client-supplied HTTP request headers (i.e., variables whose names begin with HTTP_). The presence or absence of these variables should correspond with the presence or absence of the appropriate HTTP header in the request. See RFC3875 section 4.1.18 for specific behavior.

In addition to this, the Rack environment must include these Rack-specific variables:

rack.version

The Array representing this version of Rack See Rack::VERSION, that corresponds to the version of this SPEC.

rack.url_scheme

http or https, depending on the request URL.

rack.input

See below, the input stream.

rack.errors

See below, the error stream.

rack.hijack?

present and true if the server supports connection hijacking. See below, hijacking.

rack.hijack

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.

rack.hijack_io

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.

rack.session

A hash like interface for storing request session data. The store must implement: store(key, value) (aliased as []=); fetch(key, default = nil) (aliased as []); delete(key); clear; to_hash (returning unfrozen Hash instance);

rack.logger

A common object interface for logging messages. The object must implement:

info(message, &block)
debug(message, &block)
warn(message, &block)
error(message, &block)
fatal(message, &block)

rack.multipart.buffer_size

An Integer hint to the multipart parser as to what chunk size to use for reads and writes.

rack.multipart.tempfile_factory

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 rack. is reserved for use with the Rack core distribution and other accepted specifications and must not be used otherwise.

The SERVER_PORT must be an Integer if set. The SERVER_NAME must be a valid authority as defined by RFC7540. The HTTP_HOST must be a valid authority as defined by RFC7540. The environment must not contain the keys HTTP_CONTENT_TYPE or HTTP_CONTENT_LENGTH (use the versions without HTTP_). The CGI keys (named without a period) must have String values. If the string values for CGI keys contain non-ASCII characters, they should use ASCII-8BIT encoding. There are the following restrictions:

• rack.version must be an array of Integers.

• rack.url_scheme must either be http or https.

• There must be a valid input stream in rack.input.

• There must be a valid error stream in rack.errors.

• There may be a valid hijack stream in rack.hijack_io

• The REQUEST_METHOD must be a valid token.

• The SCRIPT_NAME, if non-empty, must start with /

• The PATH_INFO, if non-empty, must start with /

• The CONTENT_LENGTH, if given, must consist of digits only.

• One of SCRIPT_NAME or PATH_INFO must be set. PATH_INFO should be / if SCRIPT_NAME is empty. SCRIPT_NAME never should be /, but instead be empty.

The Input Stream¶ ↑

The input stream is an IO-like object which contains the raw HTTP POST data. When applicable, its external encoding must be “ASCII-8BIT” and it must be opened in binary mode, for Ruby 1.9 compatibility. 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 behaves like IO#read. Its signature is read([length, [buffer]]).

  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.

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

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: read, write, read_nonblock, write_nonblock, flush, close, close_read, close_write, closed?

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 rack.hijack to an object that responds to call accepting an argument that conforms to the rack.hijack_io 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 body part of the response tuple when the rack.hijack response API is in use.

The special response header rack.hijack must only be set if the request env has rack.hijack? true.

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. It must be an Integer greater than or equal to 100.

The Headers¶ ↑

The headers must be a unfrozen Hash. The header keys must be Strings. Special headers starting “rack.” are for communicating with the server, and must not be sent back to the client. The header must not contain a Status key. Header keys must conform to RFC7230 token specification, i.e. cannot contain non-printable ASCII, DQUOTE or “(),/:;<=>?@[]{}”. Header keys must not contain uppercase ASCII characters (A-Z). Header values must be either a String instance, or an Array of String instances, such that each String instance must not contain characters below 037.

The content-type¶ ↑

There must not be a content-type header key when the Status is 1xx, 204, or 304.

The content-length¶ ↑

There must not be a content-length header key when the Status is 1xx, 204, or 304.

The Body¶ ↑

The Body is typically an Array of String instances, an enumerable that yields String instances, a Proc instance, or a File-like object.

The Body must respond to each or call. It may optionally respond to to_path.

A Body that responds to each is considered to be an Enumerable Body.

A Body that responds to call is considered to be a Streaming Body.

A Body that responds to to_path is expected to generate the same content as would be produced by reading a local file opened with the path returned by calling to_path.

A body that responds to both each and call must be treated as an Enumerable Body, not a Streaming Body. If it responds to each, you must call each and not call. If the body doesn’t respond to each, then you can assume it responds to call.

Enumerable Body¶ ↑

The Enumerable Body must respond to each. It must only be called once. and must only yield String values.

The Body itself should not be an instance of String, as this will break in Ruby 1.9.

Middleware must not call each directly on the Body. Instead, middleware can return a new Body that calls each on the original Body, yielding at least once per iteration.

If the Body responds to to_ary, it must return an Array whose contents are identical to that produced by calling each. Middleware may call to_ary directly on the Body and return a new Body in its place. In other words, middleware can only process the Body directly if it responds to to_ary.

If the Body responds to close, it will be called after iteration. If the original Body is replaced by a new Body, the new Body must close the original Body after iteration, if it responds to close. If the Body responds to both to_ary and close, its implementation of to_ary must call close after iteration.

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 server as an alternative, possibly more efficient way to transport the response.

The Body commonly is an Array of Strings, the application instance itself, or a File-like object.

Streaming Body¶ ↑

The Streaming Body must respond to call. It must only be called once. It takes a stream argument.

The stream argument must implement: read, write, flush, close, close_read, close_write, closed?

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 HTTP/2.

Thanks¶ ↑

Some parts of this specification are adopted from PEP333: Python Web Server Gateway Interface v1.0 (www.python.org/dev/peps/pep-0333/). I’d like to thank everyone involved in that effort.