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

Run a Warp server with the given settings.

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.

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 }

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

Port to listen on. Default value: 3000

Default value: HostIPv4

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.

What to do when a connection is open. Default: do nothing.

What to do when a connection is close. Default: do nothing.

Timeout value in seconds. Default value: 30

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

Cache duratoin time of file descriptors in seconds. 0 means that the cache mechanism is not used. Default value: 10

If True, each request/response pair will run in a separate ResourceT. This provides more intuitive behavior for dynamic code, but can hinder performance in high-throughput cases. File servers can safely set to False for increased performance. Default is True.

Code to run after the listening socket is ready but before entering the main event loop. Useful for signaling to tests that they can start running, or to drop permissions after binding to a restricted port.

Default: do nothing.

Since 1.3.6

Server name to be sent in the Server header.

Default: Warp/version

Since 1.3.8

Which host to bind.

Note: The IsString instance recognizes the following special values:

• * means HostAny
• *4 means HostIPv4
• *6 means HostIPv6

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.

Allows you to provide a function which will return a Connection. In cases where creating the Connection can be expensive, this allows the expensive computations to be performed in a separate thread instead of the main server loop.

Since 1.3.5

TCP port number

A timeout manager

A handle used by Manager

First field is action to be performed on timeout.

Call the inner function with a timeout manager.

A dummy Cleaner, intended for applications making use of the low-level request parsing and rendering functions.

Since 1.3.4

Default action value for Connection