Network.Wai.Handler.Warp

A fast, light-weight HTTP server handler for WAI. Some random notes (a FAQ, if you will):

• When a ResponseFile indicates a file which does not exist, an exception is thrown. This will close the connection to the client as well. You should handle file existance checks at the application level.

Run a Warp server

run :: Port -> Application -> IO ()

Run an Application on the given port. This calls runSettings with defaultSettings.

runSettings :: Settings -> Application -> IO ()

Run a Warp server with the given settings.

runSettingsSocket :: Settings -> Socket -> Application -> IO ()

Same as runSettings, but uses a user-supplied socket instead of opening one. This allows the user to provide, for example, Unix named socket, which can be used when reverse HTTP proxying into your application.

Note that the settingsPort will still be passed to Applications via the serverPort record.

Settings

data Settings

Various Warp server settings. This is purposely kept as an abstract data type so that new settings can be added without breaking backwards compatibility. In order to create a Settings value, use defaultSettings and record syntax to modify individual records. For example:

 defaultSettings { settingsTimeout = 20 }

defaultSettings :: Settings

The default settings for the Warp server. See the individual settings for the default value.

settingsPort :: Settings -> Int

Port to listen on. Default value: 3000

settingsHost :: Settings -> String

Host to bind to, or * for all. Default value: *

settingsOnException :: Settings -> SomeException -> IO ()

What to do with exceptions thrown by either the application or server. Default: ignore server-generated exceptions (see InvalidRequest) and print application-generated applications to stderr.

settingsTimeout :: Settings -> Int

Timeout value in seconds. Default value: 30

settingsIntercept :: Settings -> Request -> Maybe (BufferedSource IO ByteString -> Connection -> ResourceT IO ())

settingsManager :: Settings -> Maybe Manager

Use an existing timeout manager instead of spawning a new one. If used, settingsTimeout is ignored. Default is Nothing

Connection

data Connection

In order to provide slowloris protection, Warp provides timeout handlers. We follow these rules:

• A timeout is created when a connection is opened.
• When all request headers are read, the timeout is tickled.
• Every time at least 2048 bytes of the request body are read, the timeout is tickled.
• The timeout is paused while executing user code. This will apply to both the application itself, and a ResponseSource response. The timeout is resumed as soon as we return from user code.
• Every time data is successfully sent to the client, the timeout is tickled.

Constructors

Connection

Fields

connSendMany :: [ByteString] -> IO ()

connSendAll :: ByteString -> IO ()

connSendFile :: FilePath -> Integer -> Integer -> IO () -> IO ()

offset, length

connClose :: IO ()

connRecv :: IO ByteString

runSettingsConnection :: Settings -> IO (Connection, SockAddr) -> Application -> IO ()

Datatypes

type Port = Int

data InvalidRequest

Constructors

NotEnoughLines [String]

BadFirstLine String

NonHttp

IncompleteHeaders

OverLargeHeader

Instances

Eq InvalidRequest

Show InvalidRequest

Typeable InvalidRequest

Exception InvalidRequest

Internal

data Manager

A timeout manager

withManager

Arguments

:: Int

timeout in microseconds

-> (Manager -> IO a)

-> IO a

Call the inner function with a timeout manager.

parseRequest :: Port -> SockAddr -> BufferedSource IO ByteString -> ResourceT IO Request

sendResponse :: Handle -> Request -> Connection -> Response -> ResourceT IO Bool

registerKillThread :: Manager -> IO Handle

bindPort :: Int -> String -> IO Socket

cancel, resume, pause :: Handle -> IO ()

register :: Manager -> IO () -> IO Handle

initialize :: Int -> IO Manager