You are viewing the documentation for the 2.5.17 release in the 2.5.x series of releases. The latest stable release series is 3.0.x.

§WebSockets

WebSockets are sockets that can be used from a web browser based on a protocol that allows two way full duplex communication. The client can send messages and the server can receive messages at any time, as long as there is an active WebSocket connection between the server and the client.

Modern HTML5 compliant web browsers natively support WebSockets via a JavaScript WebSocket API. However WebSockets are not limited in just being used by WebBrowsers, there are many WebSocket client libraries available, allowing for example servers to talk to each other, and also native mobile apps to use WebSockets. Using WebSockets in these contexts has the advantage of being able to reuse the existing TCP port that a Play server uses.

Tip: Check caniuse.com to see more about which browsers supports WebSockets, known issues and more information.

§Handling WebSockets

Until now, we were using Action instances to handle standard HTTP requests and send back standard HTTP responses. WebSockets are a totally different beast and can’t be handled via standard Action.

Play provides two different built in mechanisms for handling WebSockets. The first is using Akka Streams (usually with actors), and the second is using iteratees. Both of these mechanisms can be accessed using the builders provided on WebSocket.

§Handling WebSockets with Akka Streams and actors

To handle a WebSocket with an actor, we need to give Play a akka.actor.Props object that describes the actor that Play should create when it receives the WebSocket connection. Play will give us an akka.actor.ActorRef to send upstream messages to, so we can use that to help create the Props object:

import play.api.mvc._
import play.api.libs.streams._

class Controller1 @Inject() (implicit system: ActorSystem, materializer: Materializer) {

  def socket = WebSocket.accept[String, String] { request =>
    ActorFlow.actorRef(out => MyWebSocketActor.props(out))
  }
}

Note that ActorFlow.actorRef(...) can be replaced with any Akka Streams Flow[In, Out, _], but actors are generally the most straightforward way to do it.

The actor that we’re sending to here in this case looks like this:

import akka.actor._

object MyWebSocketActor {
  def props(out: ActorRef) = Props(new MyWebSocketActor(out))
}

class MyWebSocketActor(out: ActorRef) extends Actor {
  def receive = {
    case msg: String =>
      out ! ("I received your message: " + msg)
  }
}

Any messages received from the client will be sent to the actor, and any messages sent to the actor supplied by Play will be sent to the client. The actor above simply sends every message received from the client back with I received your message: prepended to it.

§Detecting when a WebSocket has closed

When the WebSocket has closed, Play will automatically stop the actor. This means you can handle this situation by implementing the actors postStop method, to clean up any resources the WebSocket might have consumed. For example:

override def postStop() = {
  someResource.close()
}

§Closing a WebSocket

Play will automatically close the WebSocket when your actor that handles the WebSocket terminates. So, to close the WebSocket, send a PoisonPill to your own actor:

import akka.actor.PoisonPill

self ! PoisonPill

§Rejecting a WebSocket

Sometimes you may wish to reject a WebSocket request, for example, if the user must be authenticated to connect to the WebSocket, or if the WebSocket is associated with some resource, whose id is passed in the path, but no resource with that id exists. Play provides acceptOrResult to address this, allowing you to return either a result (such as forbidden, or not found), or the actor to handle the WebSocket with:

import scala.concurrent.Future
import play.api.mvc._
import play.api.libs.streams._

class Controller3 @Inject() (implicit system: ActorSystem, materializer: Materializer) extends play.api.mvc.Controller {
  def socket = WebSocket.acceptOrResult[String, String] { request =>
    Future.successful(request.session.get("user") match {
      case None => Left(Forbidden)
      case Some(_) => Right(ActorFlow.actorRef(MyWebSocketActor.props))
    })
  }
}

Note: the WebSocket protocol does not implement Same Origin Policy, and so does not protect against Cross-Site WebSocket Hijacking. To secure a websocket against hijacking, the Origin header in the request must be checked against the server’s origin, and manual authentication (including CSRF tokens) should be implemented. If a WebSocket request does not pass the security checks, then acceptOrResult should reject the request by returning a Forbidden result.

§Handling different types of messages

So far we have only seen handling String frames. Play also has built in handlers for Array[Byte] frames, and JsValue messages parsed from String frames. You can pass these as the type parameters to the WebSocket creation method, for example:

import play.api.libs.json.JsValue
import play.api.mvc._
import play.api.libs.streams._

class Controller4 @Inject() (implicit system: ActorSystem, materializer: Materializer) {
  import akka.actor._

  class MyWebSocketActor(out: ActorRef) extends Actor {
    import play.api.libs.json.JsValue
    def receive = {
      case msg: JsValue =>
        out ! msg
    }
  }

  object MyWebSocketActor {
    def props(out: ActorRef) = Props(new MyWebSocketActor(out))
  }

  def socket = WebSocket.accept[JsValue, JsValue] { request =>
    ActorFlow.actorRef(out => MyWebSocketActor.props(out))
  }

}

You may have noticed that there are two type parameters, this allows us to handle differently typed messages coming in to messages going out. This is typically not useful with the lower level frame types, but can be useful if you parse the messages into a higher level type.

For example, let’s say we want to receive JSON messages, and we want to parse incoming messages as InEvent and format outgoing messages as OutEvent. The first thing we want to do is create JSON formats for out InEvent and OutEvent types:

import play.api.libs.json._

implicit val inEventFormat = Json.format[InEvent]
implicit val outEventFormat = Json.format[OutEvent]

Now we can create a MessageFlowTransformer for these types:

import play.api.mvc.WebSocket.FrameFormatter

implicit val messageFlowTransformer = MessageFlowTransformer.jsonMessageFlowTransformer[InEvent, OutEvent]

And finally, we can use these in our WebSocket:

import play.api.libs.json._
import play.api.mvc._
import play.api.libs.streams._

// Note: requires implicit ActorSystem and Materializer (inject into your controller)
def socket = WebSocket.accept[InEvent, OutEvent] { request =>
  ActorFlow.actorRef(out => MyWebSocketActor.props(out))
}

Now in our actor, we will receive messages of type InEvent, and we can send messages of type OutEvent.

§Handling WebSockets with iteratees

To handle a WebSocket request, use a WebSocket instead of an Action:

import play.api.mvc._
import play.api.libs.iteratee._
import play.api.libs.concurrent.Execution.Implicits.defaultContext

def socket = WebSocket.using[String] { request =>

  // Log events to the console
  val in = Iteratee.foreach[String](println).map { _ =>
    println("Disconnected")
  }

  // Send a single 'Hello!' message
  val out = Enumerator("Hello!")

  (in, out)
}

A WebSocket has access to the request headers (from the HTTP request that initiates the WebSocket connection), allowing you to retrieve standard headers and session data. However, it doesn’t have access to a request body, nor to the HTTP response.

When constructing a WebSocket this way, we must return both in and out channels.

The in channel is an Iteratee[A,Unit] (where A is the message type - here we are using String) that will be notified for each message, and will receive EOF when the socket is closed on the client side.
The out channel is an Enumerator[A] that will generate the messages to be sent to the Web client. It can close the connection on the server side by sending EOF.

In this example we are creating a simple iteratee that prints each message to console. To send messages, we create a simple dummy enumerator that will send a single Hello! message.

Tip: You can test WebSockets on https://www.websocket.org/echo.html. Just set the location to ws://localhost:9000.

Let’s write another example that discards the input data and closes the socket just after sending the Hello! message:

import play.api.mvc._
import play.api.libs.iteratee._

def socket = WebSocket.using[String] { request =>

  // Just ignore the input
  val in = Iteratee.ignore[String]

  // Send a single 'Hello!' message and close
  val out = Enumerator("Hello!").andThen(Enumerator.eof)

  (in, out)
}

Here is another example in which the input data is logged to standard out and broadcast to the client utilizing Concurrent.broadcast.

import play.api.mvc._
import play.api.libs.iteratee._
import play.api.libs.concurrent.Execution.Implicits.defaultContext

def socket = WebSocket.using[String] { request =>

  // Concurrent.broadcast returns (Enumerator, Concurrent.Channel)
  val (out, channel) = Concurrent.broadcast[String]

  // log the message to stdout and send response back to client
  val in = Iteratee.foreach[String] {
    msg => println(msg)
      // the Enumerator returned by Concurrent.broadcast subscribes to the channel and will
      // receive the pushed messages
      channel push("I received your message: " + msg)
  }
  (in,out)
}

§Configuring WebSocket Frame Length

You can configure the max length for WebSocket data frames using play.websocket.buffer.limit or passing -Dwebsocket.buffer.limit system property when running your application. For example:

sbt -Dwebsocket.buffer.limit=64k run

This configuration gives you more control of WebSocket frame length and can be adjusted to your application requirements. It may also reduce denial of service attacks using long data frames.

Next: The Twirl template engine