From 520f39af9592adfa27b35b945e4ba4d10d7064a6 Mon Sep 17 00:00:00 2001 From: Shivaram Lingamneni Date: Tue, 6 Aug 2024 18:28:21 -0400 Subject: [PATCH] websocket: servers MUST support both binary and text --- extensions/websocket.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/websocket.md b/extensions/websocket.md index a1338886f..3c42313bc 100644 --- a/extensions/websocket.md +++ b/extensions/websocket.md @@ -18,7 +18,7 @@ This specification describes a mechanism for WebSocket-based clients (in particu WebSocket is a message-based protocol, i.e., it handles message fragmentation and termination internally. It offers two message types, binary and text; each has advantages and disadvantages as a transport for IRC. Binary messages can transport arbitrary bytes and therefore any valid IRC line, while text messages must consist entirely of UTF-8 data. Consequently, binary frames are necessary to fully support IRC communities that use encodings other than UTF-8. On the other hand, given that web browsers are pushing increasingly towards UTF-8 as the default encoding for HTML5 documents and scripting languages, text messages make it simpler to achieve a correct implementation on the client side. -We define two [WebSocket subprotocols](https://tools.ietf.org/html/rfc6455#section-1.9): `binary.ircv3.net` and `text.ircv3.net`. Servers implementing this specification MUST support `binary.ircv3.net` and SHOULD support `text.ircv3.net`. Clients implementing this specification MUST initially request one or both of these subprotocols, in order of preference (most preferred first). The server MUST accept any subprotocol it supports, respecting the client's order of preference. If no subprotocol can be agreed on, the server MAY continue connection establishment without sending the `Sec-WebSocket-Protocol` header. +We define two [WebSocket subprotocols](https://tools.ietf.org/html/rfc6455#section-1.9): `binary.ircv3.net` and `text.ircv3.net`. Servers implementing this specification MUST support both subprotocols. Clients implementing this specification MUST initially request one or both of these subprotocols, in order of preference (most preferred first). The server MUST accept any subprotocol it supports, respecting the client's order of preference. If no subprotocol can be agreed on, the server MAY continue connection establishment without sending the `Sec-WebSocket-Protocol` header. If `binary.ircv3.net` is negotiated, then client and server will exchange binary messages; if `text.ircv3.net` is negotiated, then they will exchange text messages. If no subprotocol is successfully negotiated, server and client MAY implement fallbacks designed for compatibility with legacy software; the exact behavior is left implementation-defined. In all cases, the message format is the same: each message MUST consist of a single IRC line, except that servers and clients MUST NOT include trailing `\r` or `\n` characters in the message.