WebSockets 0.11



Published on April 16, 2017 under the tag Update on the Haskell WebSockets libraryPublished on April 16, 2017 under the tag haskell

Introduction

Today, I released version 0.11 of the Haskell websockets library. Minor changes include:

Support for IPv6 in the built-in server, client and tests (thanks to agentm).

Faster masking (thanks to Dmitry Ivanov).

But most importantly, this release adds support for the permessage-deflate extension as described in RFC 7692. A big thanks go out to Marcin Tolysz who first submitted patches for an implementation. Unfortunately, merging these patches turned out to be a rocky road.

Autobahn

After merging all these changes and improving upon them, I’m very happy that the library now passes the Autobahn Testsuite. This language-agnostic testsuite is very extensive and contains test cases covering most of the protocol surface.

Autobahn

When I started running this testsuite against the websockets library, it was very encouraging to learn that – apart from a few corner cases – it was already passing most of this testsuite without any additional work.

The majority of failing tests were caused by the problem that the Haskell websockets library was too lenient: it would accept invalid UTF-8 characters when reading the messages as a ByteString . The RFC, however, dictates that a server should immediately close the connection if the client sends invalid UTF-8.

This has now been rectified, but as an opt-in, in order not to break any existing applications using this library. For example, in order to enable the new compression and UTF-8 validation, you can use something like:

main :: IO () () = WS.runServerWith "0.0.0.0" 9001 options application mainWS.runServerWithoptions application where = WS.defaultConnectionOptions optionsWS.defaultConnectionOptions = { WS.connectionCompressionOptions WS.PermessageDeflateCompression WS.defaultPermessageDeflate WS.defaultPermessageDeflate = True , WS.connectionStrictUnicode }

Note that if you are already decoding the incoming messages to Text values through the WebSocketsData interface, enabling connectionStrictUnicode should not add any additional overhead. On the other hand, if your application is a proxy which just takes the ByteString s and sends them through, enabling UTF-8 validation will of course come at a price.

In a future release, permessage-deflate will be enabled by default.

Other things

I realise that this blog has been a little quiet lately. This is because (aside from work being busy) I’ve been involved in some other things: