server is:module

This module lets you implement Servers for defined APIs. You'll most likely just need serve.

Happstack.Server provides a self-contained HTTP server and a rich collection of types and functions for routing Requests, generating Responses, working with query parameters, form data, and cookies, serving files and more. A very simple, "Hello World!" web app looks like:

import Happstack.Server
main = simpleHTTP nullConf $ ok "Hello World!"

By default the server will listen on port 8000. Run the app and point your browser at: http://localhost:8000/ At the core of the Happstack server we have the simpleHTTP function which starts the HTTP server:

simpleHTTP :: ToMessage a => Conf -> ServerPart a -> IO ()

and we have the user supplied ServerPart (also known as, ServerPartT IO), which generates a Response for each incoming Request. A trivial HTTP app server might just take a user supplied function like:

myApp :: Request -> IO Response

For each incoming Request the server would fork a new thread, run myApp to generate a Response, and then send the Response back to the client. But, that would be a pretty barren wasteland to work in. The model for ServerPart is essential the same, except we use the much richer ServerPart monad instead of the IO monad. For in-depth documentation and runnable examples I highly recommend The Happstack Crash Course http://happstack.com/docs/crashcourse/index.html.

The Snap HTTP server is a high performance web server library written in Haskell. Together with the snap-core library upon which it depends, it provides a clean and efficient Haskell programming interface to the HTTP protocol.

HTTP/2 server library. Example:

{-# LANGUAGE OverloadedStrings #-}
module Main (main) where

import qualified Control.Exception as E
import Data.ByteString.Builder (byteString)
import Network.HTTP.Types (ok200)
import Network.Run.TCP (runTCPServer) -- network-run

import Network.HTTP2.Server

main :: IO ()
main = runTCPServer Nothing "80" runHTTP2Server
where
runHTTP2Server s = E.bracket (allocSimpleConfig s 4096)
freeSimpleConfig
(\config -> run defaultServerConfig config server)
server _req _aux sendResponse = sendResponse response []
where
response = responseBuilder ok200 header body
header = [("Content-Type", "text/plain")]
body = byteString "Hello, world!\n"

This module contains the server functionality of XML-RPC. The XML-RPC specifcation is available at http://www.xmlrpc.com/spec. A simple CGI-based XML-RPC server application:

import Network.XmlRpc.Server

add :: Int -> Int -> IO Int
add x y = return (x + y)

main = cgiXmlRpcServer [("examples.add", fun add)]

The Server Portion of the Managed Process API.

Main entry point into the Hackage Security framework for clients

Handles the connections between a Memcached client and a single server. Memcached expected errors (part of protocol) are returned in the Response, unexpected errors (e.g., network failure) are thrown as exceptions. While the Server datatype supports a failed and failedAt flag for managing retries, it's up to consumers to use this.

Semantics of requests that are sent by clients to the server, in terms of game state changes and responses to be sent to the clients. See https://github.com/LambdaHack/LambdaHack/wiki/Client-server-architecture.

Server provides a basic implementation of an HTTP server. The recommended usage of this server is for internal use, tasks like a mock server for tests, a private service for IPC, etc. It is not recommended to be exposed to untrusted clients as it may be vulnerable to denial of service attacks or other exploits. To begin, create a server using [ctorserver.new]. Add at least one handler by calling [methodserver.add_handler] or [methodserver.add_early_handler]; the handler will be called to process any requests underneath the path you pass. (If you want all requests to go to the same handler, just pass "/" (or Nothing) for the path.) When a new connection is accepted (or a new request is started on an existing persistent connection), the Server will emit signalserver[requestStarted] and then begin processing the request as described below, but note that once the message is assigned a status-code, then callbacks after that point will be skipped. Note also that it is not defined when the callbacks happen relative to various [classserverMessage] signals. Once the headers have been read, Server will check if there is a [classauthDomain] (qv) covering the Request-URI; if so, and if the message does not contain suitable authorization, then the [classauthDomain] will set a status of StatusUnauthorized on the message. After checking for authorization, Server will look for "early" handlers (added with [methodserver.add_early_handler]) matching the Request-URI. If one is found, it will be run; in particular, this can be used to connect to signals to do a streaming read of the request body. (At this point, if the request headers contain Expect: 100-continue, and a status code has been set, then Server will skip the remaining steps and return the response. If the request headers contain Expect: 100-continue and no status code has been set, Server will return a StatusContinue status before continuing.) The server will then read in the response body (if present). At this point, if there are no handlers at all defined for the Request-URI, then the server will return StatusNotFound to the client. Otherwise (assuming no previous step assigned a status to the message) any "normal" handlers (added with [methodserver.add_handler]) for the message's Request-URI will be run. Then, if the path has a WebSocket handler registered (and has not yet been assigned a status), Server will attempt to validate the WebSocket handshake, filling in the response and setting a status of StatusSwitchingProtocols or StatusBadRequest accordingly. If the message still has no status code at this point (and has not been paused with [methodserverMessage.pause]), then it will be given a status of StatusInternalServerError (because at least one handler ran, but returned without assigning a status). Finally, the server will emit signalserver[requestFinished] (or signalserver[requestAborted] if an I/O error occurred before handling was completed). If you want to handle the special "*" URI (eg, "OPTIONS *"), you must explicitly register a handler for "*"; the default handler will not be used for that case. If you want to process https connections in addition to (or instead of) http connections, you can set the [propertyserver:tls-certificate] property. Once the server is set up, make one or more calls to [methodserver.listen], [methodserver.listen_local], or [methodserver.listen_all] to tell it where to listen for connections. (All ports on a Server use the same handlers; if you need to handle some ports differently, such as returning different data for http and https, you'll need to create multiple SoupServers, or else check the passed-in URI in the handler function.). Server will begin processing connections as soon as you return to (or start) the main loop for the current thread-default MainContext.

GraphQL Wai Server Applications

Serve pages via ScottyM

A server which represents a sharing of a set of DbusmenuMenuitems across DBus to a Client.

Serve a chart web page with a web socket in it, that accepts ChartOptions.

This module exports HasServer instances for Throws and Throwing.