websockets-0.13.0.0: A sensible and clean way to write WebSocket-capable servers in Haskell.
Safe HaskellSafe-Inferred
LanguageHaskell2010

Network.WebSockets

Synopsis

Incoming connections and handshaking

data PendingConnection Source #

A new client connected to the server. We haven't accepted the connection yet, though.

pendingRequest :: PendingConnection -> RequestHead Source #

Useful for e.g. inspecting the request path.

acceptRequest :: PendingConnection -> IO Connection Source #

Accept a pending connection, turning it into a Connection.

data AcceptRequest Source #

This datatype allows you to set options for acceptRequestWith. It is strongly recommended to use defaultAcceptRequest and then modify the various fields, that way new fields introduced in the library do not break your code.

Constructors

AcceptRequest 

Fields

acceptRequestWith :: PendingConnection -> AcceptRequest -> IO Connection Source #

This function is like acceptRequest but allows you to set custom options using the AcceptRequest datatype.

rejectRequest Source #

Arguments

:: PendingConnection

Connection to reject

-> ByteString

Rejection response body

-> IO () 

Requires calling pendingStream and close.

data RejectRequest Source #

Parameters that allow you to tweak how a request is rejected. Please use defaultRejectRequest and modify fields using record syntax so your code will not break when new fields are added.

Constructors

RejectRequest 

Fields

rejectRequestWith Source #

Arguments

:: PendingConnection

Connection to reject

-> RejectRequest

Params on how to reject the request

-> IO () 

Main connection type

Options for connections

data ConnectionOptions Source #

Set options for a Connection. Please do not use this constructor directly, but rather use defaultConnectionOptions and then set the fields you want, e.g.:

myOptions = defaultConnectionOptions {connectionStrictUnicode = True}

This way your code does not break if the library introduces new fields.

Constructors

ConnectionOptions 

Fields

  • connectionOnPong :: !(IO ())

    Whenever a pong is received, this IO action is executed. It can be used to tickle connections or fire missiles.

  • connectionTimeout :: !Int

    Timeout for connection establishment in seconds. Only used in the client.

  • connectionCompressionOptions :: !CompressionOptions
  • connectionStrictUnicode :: !Bool

    Enable strict unicode on the connection. This means that if a client (or server) sends invalid UTF-8, we will throw a UnicodeException rather than replacing it by the unicode replacement character U+FFFD.

  • connectionFramePayloadSizeLimit :: !SizeLimit

    The maximum size for incoming frame payload size in bytes. If a frame exceeds this limit, a ParseException is thrown.

  • connectionMessageDataSizeLimit :: !SizeLimit

    connectionFrameSizeLimit is often not enough since a malicious client can send many small frames to create a huge message. This limit allows you to protect from that. If a message exceeds this limit, a ParseException is thrown.

    Note that, if compression is enabled, we check the size of the compressed messages, as well as the size of the uncompressed messages as we are deflating them to ensure we don't use too much memory in any case.

defaultConnectionOptions :: ConnectionOptions Source #

The default connection options:

  • Nothing happens when a pong is received.
  • Compression is disabled.
  • Lenient unicode decoding.
  • 30 second timeout for connection establishment.

Compression options

data PermessageDeflate Source #

Four extension parameters are defined for "permessage-deflate" to help endpoints manage per-connection resource usage.

  • "server_no_context_takeover"
  • "client_no_context_takeover"
  • "server_max_window_bits"
  • "client_max_window_bits"

Protection limits

data SizeLimit Source #

A size limit, in bytes. The Monoid instance takes the minimum limit.

Constructors

NoSizeLimit 
SizeLimit !Int64 

Sending and receiving messages

receiveDataMessage :: Connection -> IO DataMessage Source #

Receive an application message. Automatically respond to control messages.

When the peer sends a close control message, an exception of type CloseRequest is thrown. The peer can send a close control message either to initiate a close or in response to a close message we have sent to the peer. In either case the CloseRequest exception will be thrown. The RFC specifies that the server is responsible for closing the TCP connection, which should happen after receiving the CloseRequest exception from this function.

This will throw ConnectionClosed if the TCP connection dies unexpectedly.

receiveData :: WebSocketsData a => Connection -> IO a Source #

Receive a message, converting it to whatever format is needed.

sendDataMessage :: Connection -> DataMessage -> IO () Source #

Send a Message. This allows you send both human-readable text and binary data. This is a slightly more low-level interface than sendTextData or sendBinaryData.

sendDataMessages :: Connection -> [DataMessage] -> IO () Source #

Send a collection of Messages. This is more efficient than calling sendDataMessage many times.

sendTextData :: WebSocketsData a => Connection -> a -> IO () Source #

Send a textual message. The message will be encoded as UTF-8. This should be the default choice for human-readable text-based protocols such as JSON.

sendTextDatas :: WebSocketsData a => Connection -> [a] -> IO () Source #

Send a number of textual messages. This is more efficient than calling sendTextData many times.

sendBinaryData :: WebSocketsData a => Connection -> a -> IO () Source #

Send a binary message. This is useful for sending binary blobs, e.g. images, data encoded with MessagePack, images...

sendBinaryDatas :: WebSocketsData a => Connection -> [a] -> IO () Source #

Send a number of binary messages. This is more efficient than calling sendBinaryData many times.

sendClose :: WebSocketsData a => Connection -> a -> IO () Source #

Send a friendly close message. Note that after sending this message, you should still continue calling receiveDataMessage to process any in-flight messages. The peer will eventually respond with a close control message of its own which will cause receiveDataMessage to throw the CloseRequest exception. This exception is when you can finally consider the connection closed.

sendCloseCode :: WebSocketsData a => Connection -> Word16 -> a -> IO () Source #

Send a friendly close message and close code. Similar to sendClose, you should continue calling receiveDataMessage until you receive a CloseRequest exception.

See http://tools.ietf.org/html/rfc6455#section-7.4 for a list of close codes.

sendPing :: WebSocketsData a => Connection -> a -> IO () Source #

Send a ping

HTTP Types

type Headers = [(CI ByteString, ByteString)] Source #

Request headers

data Request Source #

A request with a body

Instances

Instances details
Show Request Source # 
Instance details

Defined in Network.WebSockets.Http

data RequestHead Source #

An HTTP request. The request body is not yet read.

Instances

Instances details
Show RequestHead Source # 
Instance details

Defined in Network.WebSockets.Http

getRequestSubprotocols :: RequestHead -> [ByteString] Source #

List of subprotocols specified by the client, in order of preference. If the client did not specify a list of subprotocols, this will be the empty list.

data Response Source #

A response including a body

Instances

Instances details
Show Response Source # 
Instance details

Defined in Network.WebSockets.Http

data ResponseHead Source #

HTTP response, without body.

Instances

Instances details
Show ResponseHead Source # 
Instance details

Defined in Network.WebSockets.Http

WebSocket message types

data Message Source #

The kind of message a server application typically deals with

Constructors

ControlMessage ControlMessage 
DataMessage Bool Bool Bool DataMessage

Reserved bits, actual message

Instances

Instances details
Show Message Source # 
Instance details

Defined in Network.WebSockets.Types

Eq Message Source # 
Instance details

Defined in Network.WebSockets.Types

Methods

(==) :: Message -> Message -> Bool #

(/=) :: Message -> Message -> Bool #

data ControlMessage Source #

Different control messages

data DataMessage Source #

For an end-user of this library, dealing with Frames would be a bit low-level. This is why define another type on top of it, which represents data for the application layer.

There are currently two kinds of data messages supported by the WebSockets protocol:

  • Textual UTF-8 encoded data. This corresponds roughly to sending a String in JavaScript.
  • Binary data. This corresponds roughly to send an ArrayBuffer in JavaScript.

Constructors

Text ByteString (Maybe Text)

A textual message. The second field might contain the decoded UTF-8 text for caching reasons. This field is computed lazily so if it's not accessed, it should have no performance impact.

Binary ByteString

A binary message.

Instances

Instances details
Show DataMessage Source # 
Instance details

Defined in Network.WebSockets.Types

Eq DataMessage Source # 
Instance details

Defined in Network.WebSockets.Types

class WebSocketsData a where Source #

In order to have an even more high-level API, we define a typeclass for values the user can receive from and send to the socket. A few warnings apply:

  • Natively, everything is represented as a ByteString, so this is the fastest instance
  • You should only use the Text or the Text instance when you are sure that the data is UTF-8 encoded (which is the case for Text messages).
  • Messages can be very large. If this is the case, it might be inefficient to use the strict ByteString and Text instances.

Exceptions

data HandshakeException Source #

Error in case of failed handshake. Will be thrown as an Exception.

TODO: This should probably be in the Handshake module, and is solely here to prevent a cyclic dependency.

Constructors

NotSupported

We don't have a match for the protocol requested by the client. todo: version parameter

MalformedRequest RequestHead String

The request was somehow invalid (missing headers or wrong security token)

MalformedResponse ResponseHead String

The servers response was somehow invalid (missing headers or wrong security token)

RequestRejected RequestHead ResponseHead

The request was well-formed, but the library user rejected it. (e.g. "unknown path")

ConnectionTimeout

The connection timed out

OtherHandshakeException String

for example "EOF came too early" (which is actually a parse error) or for your own errors. (like "unknown path"?)

data ConnectionException Source #

Various exceptions that can occur while receiving or transmitting messages

Constructors

CloseRequest Word16 ByteString

The peer has requested that the connection be closed, and included a close code and a reason for closing. When receiving this exception, no more messages can be sent. Also, the server is responsible for closing the TCP connection once this exception is received.

See http://tools.ietf.org/html/rfc6455#section-7.4 for a list of close codes.

ConnectionClosed

The peer unexpectedly closed the connection while we were trying to receive some data. This is a violation of the websocket RFC since the TCP connection should only be closed after sending and receiving close control messages.

ParseException String

The client sent garbage, i.e. we could not parse the WebSockets stream.

UnicodeException String

The client sent invalid UTF-8. Note that this exception will only be thrown if strict decoding is set in the connection options.

Running a standalone server

type ServerApp = PendingConnection -> IO () Source #

WebSockets application that can be ran by a server. Once this IO action finishes, the underlying socket is closed automatically.

runServer Source #

Arguments

:: String

Address to bind

-> Int

Port to listen on

-> ServerApp

Application

-> IO ()

Never returns

Provides a simple server. This function blocks forever. Note that this is merely provided for quick-and-dirty or internal applications, but for real applications, you should use a real server.

For example:

  • Performance is reasonable under load, but:
  • No protection against DoS attacks is provided.
  • No logging is performed.
  • ...

Glue for using this package with real servers is provided by:

runServerWith :: String -> Int -> ConnectionOptions -> ServerApp -> IO () Source #

Deprecated: Use runServerWithOptions instead

A version of runServer which allows you to customize some options.

runServerWithOptions :: ServerOptions -> ServerApp -> IO a Source #

Customizable version of runServer. Never returns until killed.

Please use the defaultServerOptions combined with record updates to set the fields you want. This way your code is unlikely to break on future changes.

Utilities for writing your own server

makeListenSocket :: String -> Int -> IO Socket Source #

Create a standardized socket on which you can listen for incomming connections. Should only be used for a quick and dirty solution! Should be preceded by the call withSocketsDo.

makePendingConnection :: Socket -> ConnectionOptions -> IO PendingConnection Source #

Turns a socket, connected to some client, into a PendingConnection. The PendingConnection should be closed using pendingStream and close later.

Running a client

type ClientApp a = Connection -> IO a Source #

A client application interacting with a single server. Once this IO action finished, the underlying socket is closed automatically.

runClient Source #

Arguments

:: String

Host

-> Int

Port

-> String

Path

-> ClientApp a

Client application

-> IO a 

runClientWith Source #

Arguments

:: String

Host

-> Int

Port

-> String

Path

-> ConnectionOptions

Options

-> Headers

Custom headers to send

-> ClientApp a

Client application

-> IO a 

runClientWithSocket Source #

Arguments

:: Socket

Socket

-> String

Host

-> String

Path

-> ConnectionOptions

Options

-> Headers

Custom headers to send

-> ClientApp a

Client application

-> IO a 

runClientWithStream Source #

Arguments

:: Stream

Stream

-> String

Host

-> String

Path

-> ConnectionOptions

Connection options

-> Headers

Custom headers to send

-> ClientApp a

Client application

-> IO a 

newClientConnection Source #

Arguments

:: Stream

Stream that will be used by the new Connection.

-> String

Host

-> String

Path

-> ConnectionOptions

Connection options

-> Headers

Custom headers to send

-> IO Connection 

Build a new Connection from the client's point of view.

WARNING: Be sure to call close on the given Stream after you are done using the Connection in order to properly close the communication channel. runClientWithStream handles this for you, prefer to use it when possible.

Utilities

data PingPongOptions Source #

Options for ping-pong

Make sure that the ping interval is less than the pong timeout, for example N/2.

Constructors

PingPongOptions 

Fields

defaultPingPongOptions :: PingPongOptions Source #

Default options for ping-pong

Ping every 15 seconds, timeout after 30 seconds

withPingPong :: PingPongOptions -> Connection -> (Connection -> IO ()) -> IO () Source #

Run an application with ping-pong enabled. Raises PongTimeout if a pong is not received.

Can used with Client and Server connections.

withPingThread Source #

Arguments

:: Connection 
-> Int

Second interval in which pings should be sent.

-> IO ()

Repeat this after sending a ping.

-> IO a

Application to wrap with a ping thread.

-> IO a

Executes application and kills ping thread when done.

Forks a ping thread, sending a ping message every n seconds over the connection. The thread is killed when the inner IO action is finished.

This is useful to keep idle connections open through proxies and whatnot. Many (but not all) proxies have a 60 second default timeout, so based on that sending a ping every 30 seconds is a good idea.

Note that usually you want to use withPingPong to timeout the connection if a pong is not received.

forkPingThread :: Connection -> Int -> IO () Source #

Deprecated: Use withPingThread instead

DEPRECATED: Use withPingThread instead.

Forks a ping thread, sending a ping message every n seconds over the connection. The thread dies silently if the connection crashes or is closed.

This is useful to keep idle connections open through proxies and whatnot. Many (but not all) proxies have a 60 second default timeout, so based on that sending a ping every 30 seconds is a good idea.