The WAI application.

Middleware is a component that sits between the server and application. It can do such tasks as GZIP encoding or response caching. What follows is the general definition of middleware, though a middleware author should feel free to modify this.

As an example of an alternate type for middleware, suppose you write a function to load up session information. The session information is simply a string map [(String, String)]. A logical type signature for this middleware might be:

 loadSession :: ([(String, String)] -> Application) -> Application

Here, instead of taking a standard Application as its first argument, the middleware takes a function which consumes the session information as well.

Information on the request sent by the client. This abstracts away the details of the underlying implementation.

A default, blank request.

Since 2.0.0

The size of the request body. In the case of chunked bodies, the size will not be known.

Since 1.4.0

Request method such as GET.

HTTP version such as 1.1.

Extra path information sent by the client. The meaning varies slightly depending on backend; in a standalone server setting, this is most likely all information after the domain name. In a CGI application, this would be the information following the path to the CGI executable itself. Do not modify this raw value- modify pathInfo instead.

If no query string was specified, this should be empty. This value will include the leading question mark. Do not modify this raw value- modify queryString instead.

A list of header (a pair of key and value) in an HTTP request.

Was this request made over an SSL connection?

Note that this value will not tell you if the client originally made this request over SSL, but rather whether the current connection is SSL. The distinction lies with reverse proxies. In many cases, the client will connect to a load balancer over SSL, but connect to the WAI handler without SSL. In such a case, isSecure will be False, but from a user perspective, there is a secure connection.

The client's host information.

Path info in individual pieces- the url without a hostname/port and without a query string, split on forward slashes.

Parsed query string information

A request body provided as Source.

A location for arbitrary data to be shared by applications and middleware.

The size of the request body. In the case of a chunked request body, this may be unknown.

Since 1.4.0

The value of the Host header in a HTTP request.

Since 2.0.0

The value of the Range header in a HTTP request.

Since 2.0.0

Get the request body as a lazy ByteString. This uses lazy I/O under the surface, and therefore all typical warnings regarding lazy I/O apply.

Since 1.4.1

The strange structure of the third field or ResponseSource is to allow for exception-safe resource allocation. As an example:

 app :: Application
 app _ = return $ ResponseSource status200 [] $ \f -> bracket
     (putStrLn "Allocation" >> return 5)
     (\i -> putStrLn $ "Cleaning up: " ++ show i)
     (\_ -> f $ do
         yield $ Chunk $ fromByteString "Hello "
         yield $ Chunk $ fromByteString "World!")

Information on which part to be sent. Sophisticated application handles Range (and If-Range) then create FilePart.

Auxiliary type for ResponseSource.

Creating Response from a file.

Creating Response from Builder.

Some questions and answers about the usage of Builder here:

Q1. Shouldn't it be at the user's discretion to use Builders internally and then create a stream of ByteStrings?

A1. That would be less efficient, as we wouldn't get cheap concatenation with the response headers.

Q2. Isn't it really inefficient to convert from ByteString to Builder, and then right back to ByteString?

A2. No. If the ByteStrings are small, then they will be copied into a larger buffer, which should be a performance gain overall (less system calls). If they are already large, then blaze-builder uses an InsertByteString instruction to avoid copying.

Q3. Doesn't this prevent us from creating comet-style servers, since data will be cached?

A3. You can force blaze-builder to output a ByteString before it is an optimal size by sending a flush command.

Creating Response from ByteString. This is a wrapper for responseBuilder.

Creating Response from Source.

Creating Response with allocated resource safely released.

• The first argument is an action to allocate resource.
• The second argument is a function to release the resource.
• The third argument is a function to create (Status,ResponseHeaders,Source IO (Flush Builder)) from the resource.

Create a response for a raw application. This is useful for "upgrade" situations such as WebSockets, where an application requests for the server to grant it raw network access.

This function requires a backup response to be provided, for the case where the handler in question does not support such upgrading (e.g., CGI apps).

In the event that you read from the request body before returning a responseRaw, behavior is undefined.

Since 2.1.0

Accessing Status in Response.

Accessing Status in Response.

Converting the body information in Response to Source.