diff --git a/akka-docs/rst/java/http/client-side/websocket-support.rst b/akka-docs/rst/java/http/client-side/websocket-support.rst index 5331ff754c..4f376771c9 100644 --- a/akka-docs/rst/java/http/client-side/websocket-support.rst +++ b/akka-docs/rst/java/http/client-side/websocket-support.rst @@ -28,7 +28,7 @@ HTTP result can be found in ``WebSocketUpgradeResponse.response`` Message ------- Messages sent and received over a WebSocket can be either :class:`TextMessage` s or :class:`BinaryMessage` s and each -of those can be either strict (all data in one chunk) or streaming. In typical applications messages will be strict as +of those can be either strict (all data in one chunk) or streamed. In typical applications messages will be strict as WebSockets are usually deployed to communicate using small messages not stream data, the protocol does however allow this (by not marking the first fragment as final, as described in `rfc 6455 section 5.2`__). @@ -37,7 +37,7 @@ __ https://tools.ietf.org/html/rfc6455#section-5.2 The strict text is available from ``TextMessage.getStrictText`` and strict binary data from ``BinaryMessage.getStrictData``. -For streaming messages ``BinaryMessage.getStreamedData`` and ``TextMessage.getStreamedText`` is used to access the data. +For streamed messages ``BinaryMessage.getStreamedData`` and ``TextMessage.getStreamedText`` is used to access the data. In these cases the data is provided as a ``Source`` for binary and ``Source`` for text messages. diff --git a/akka-docs/rst/java/http/server-side/websocket-support.rst b/akka-docs/rst/java/http/server-side/websocket-support.rst index 84c5d1c7f6..c4d699431f 100644 --- a/akka-docs/rst/java/http/server-side/websocket-support.rst +++ b/akka-docs/rst/java/http/server-side/websocket-support.rst @@ -40,7 +40,7 @@ the notion of a "strict" message to represent cases where a whole message was re When receiving data from the network connection the WebSocket implementation tries to create a strict message whenever possible, i.e. when the complete data was received in one chunk. However, the actual chunking of messages over a network connection and through the various streaming abstraction layers is not deterministic from the perspective of the -application. Therefore, application code must be able to handle both streaming and strict messages and not expect +application. Therefore, application code must be able to handle both streamed and strict messages and not expect certain messages to be strict. (Particularly, note that tests against ``localhost`` will behave differently than tests against remote peers where data is received over a physical network connection.) diff --git a/akka-docs/rst/scala/http/client-side/websocket-support.rst b/akka-docs/rst/scala/http/client-side/websocket-support.rst index 79f88e4002..f432d40a70 100644 --- a/akka-docs/rst/scala/http/client-side/websocket-support.rst +++ b/akka-docs/rst/scala/http/client-side/websocket-support.rst @@ -27,13 +27,13 @@ HTTP result can be found in ``WebSocketUpgradeResponse.response`` Message ------- Messages sent and received over a WebSocket can be either :class:`TextMessage` s or :class:`BinaryMessage` s and each -of those has two subtypes :class:`Strict` or :class:`Streaming`. In typical applications messages will be ``Strict`` as +of those has two subtypes :class:`Strict` or :class:`Streamed`. In typical applications messages will be ``Strict`` as WebSockets are usually deployed to communicate using small messages not stream data, the protocol does however allow this (by not marking the first fragment as final, as described in `rfc 6455 section 5.2`__). __ https://tools.ietf.org/html/rfc6455#section-5.2 -For such streaming messages :class:`BinaryMessage.Streaming` and :class:`TextMessage.Streaming` will be used. In these cases +For such streamed messages :class:`BinaryMessage.Streamed` and :class:`TextMessage.Streamed` will be used. In these cases the data is provided as a ``Source[ByteString, NotUsed]`` for binary and ``Source[String, NotUsed]`` for text messages. diff --git a/akka-docs/rst/scala/http/routing-dsl/websocket-support.rst b/akka-docs/rst/scala/http/routing-dsl/websocket-support.rst index cef1db7276..ff9da67297 100644 --- a/akka-docs/rst/scala/http/routing-dsl/websocket-support.rst +++ b/akka-docs/rst/scala/http/routing-dsl/websocket-support.rst @@ -33,13 +33,13 @@ a ``Strict`` subclass for each kind of message which contains data as a strict, When receiving data from the network connection the WebSocket implementation tries to create a ``Strict`` message whenever possible, i.e. when the complete data was received in one chunk. However, the actual chunking of messages over a network connection and through the various streaming abstraction layers is not deterministic from the perspective of the -application. Therefore, application code must be able to handle both streaming and strict messages and not expect +application. Therefore, application code must be able to handle both streamed and strict messages and not expect certain messages to be strict. (Particularly, note that tests against ``localhost`` will behave differently than tests against remote peers where data is received over a physical network connection.) For sending data, use ``TextMessage.apply(text: String)`` to create a ``Strict`` message which is often the natural choice when the complete message has already been assembled. Otherwise, use ``TextMessage.apply(textStream: Source[String, Any])`` -to create a streaming message from an Akka Stream source. +to create a streamed message from an Akka Stream source. Server API ----------