File: SPEC [rack-1.2.2 Documentation]

### Home Classes Methods

### Files

- KNOWN-ISSUES
- README
- SPEC

### Class Index

Quicksearch

- Rack
- Rack::Auth
- Rack::Auth::AbstractHandler
- Rack::Auth::AbstractRequest
- Rack::Auth::Basic
- Rack::Auth::Basic::Request
- Rack::Auth::Digest
- Rack::Auth::Digest::MD5
- Rack::Auth::Digest::Nonce
- Rack::Auth::Digest::Params
- Rack::Auth::Digest::Request
- Rack::Builder
- Rack::Cascade
- Rack::Chunked
- Rack::CommonLogger
- Rack::ConditionalGet
- Rack::Config
- Rack::ContentLength
- Rack::ContentType
- Rack::Deflater
- Rack::Deflater::DeflateStream
- Rack::Deflater::GzipStream
- Rack::Directory
- Rack::ETag
- Rack::File
- Rack::ForwardRequest
- Rack::Handler
- Rack::Handler::CGI
- Rack::Handler::EventedMongrel
- Rack::Handler::FastCGI
- Rack::Handler::LSWS
- Rack::Handler::Mongrel
- Rack::Handler::SCGI
- Rack::Handler::SwiftipliedMongrel
- Rack::Handler::Thin
- Rack::Handler::WEBrick
- Rack::Head
- Rack::Lint
- Rack::Lobster
- Rack::Lock
- Rack::Logger
- Rack::MethodOverride
- Rack::Mime
- Rack::MockRequest
- Rack::MockRequest::FatalWarner
- Rack::MockRequest::FatalWarning
- Rack::MockResponse
- Rack::NullLogger
- Rack::Recursive
- Rack::Reloader
- Rack::Reloader::Stat
- Rack::Request
- Rack::Response
- Rack::Response::Helpers
- Rack::RewindableInput
- Rack::RewindableInput::Tempfile
- Rack::Runtime
- Rack::Sendfile
- Rack::Server
- Rack::Server::Options
- Rack::Session
- Rack::Session::Abstract
- Rack::Session::Abstract::ID
- Rack::Session::Cookie
- Rack::Session::Memcache
- Rack::Session::Pool
- Rack::ShowExceptions
- Rack::ShowStatus
- Rack::Static
- Rack::URLMap
- Rack::Utils
- Rack::Utils::Context
- Rack::Utils::HeaderHash
- Rack::Utils::Multipart
- Rack::Utils::Multipart::UploadedFile
- FCGI
- FCGI::Stream

No matching classes.

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 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 I 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`, `SERVER_PORT` | 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` and `SERVER_PORT` can never be empty strings, and so are always required.
`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.

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

`rack.version` | The Array [1,1], representing this version of Rack.
`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.multithread` | true if the application object may be simultaneously invoked by another thread in the same process, false otherwise.
`rack.multiprocess` | true if an equivalent application object may be simultaneously invoked by another process, false otherwise.
`rack.run_once` | 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).

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;
`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)

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

- 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`, `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 `read([length, [buffer]])`. 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.

- `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: that is, it may not be a pipe or a socket. Therefore, handler developers must buffer the input data into some rewindable object if the underlying input stream is not rewindable.

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

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. The header keys must be Strings. The header must not contain a `Status` key, contain keys with `:` or newlines in their name, contain keys names that end in `-` or `_`, but only contain keys that consist of letters, digits, `_` or `-` and start with a letter. The values of the header must be Strings, consisting of lines (for multiple header values, e.g. multiple `Set-Cookie` values) seperated by “n”. The lines must not contain characters below 037.

### The Content-Type

There must be a `Content-Type`, except when the `Status` is 1xx, 204 or 304, in which case there must be none given.

### The Content-Length

There must not be a `Content-Length` header when the `Status` is 1xx, 204 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 `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.

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

[Validate]

Generated with the Darkfish Rdoc Generator 2.