commit b7bd6a2338a32fd70e5068cf2d61c01537f939e9 Author: David Fifield david@bamsoftware.com Date: Thu May 3 00:24:44 2012 -0700

Wording on buffering. --- doc/websocket-transport.txt | 13 ++++++------- 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/doc/websocket-transport.txt b/doc/websocket-transport.txt index 45de461..65b4e9c 100644 --- a/doc/websocket-transport.txt +++ b/doc/websocket-transport.txt @@ -176,13 +176,12 @@ Considerations specific to pluggable transports messages SHOULD be sent in a single frame.

Endpoints MUST limit the size of messages and frames that they will - buffer. Upon receiving such a message (when the sum of the length of - already-buffered data and the length of the next frame exceeds the - limit), the endpoint MUST close the connection and SHOULD do so with a - status code of 1009 (see RFC 6455 section 7.4.1). Endpoints MUST be - capable of receiving messages containing 1500 octets of binary data; - this may require buffering up to 2026 bytes of UTF-8–encoded base64 - text. + buffer. When the sum of the length of already-buffered data and the + length of the next frame exceeds the limit, the endpoint MUST close + the connection and SHOULD do so with a status code of 1009 (see RFC + 6455 section 7.4.1). Endpoints MUST be capable of receiving messages + containing up to 1500 octets of binary data; this may require + buffering up to 2026 bytes of UTF-8–encoded base64 text.

Questions/extensions