I assumed gorilla validated UTF8 for incoming text messages. In fact, the
documentation states:
>It is the application's responsibility to ensure that text messages
>are valid UTF-8 encoded text.
and this applies to both incoming and outgoing messages. Consequently,
even when enforce-utf8 is enabled, it was possible to send invalid UTF8
to Ergo inside a websocket text frame. This data would be incorrectly
considered valid UTF8, and could be relayed to other clients, including
to websocket clients inside a text frame. The resulting frame would violate
the websocket protocol, causing web clients to be disconnected.
1. Text and binary frames are accepted
2. Text frames are sent by default
3. Binary frames are sent to clients who negotiate `binary.ircv3.net`
4. Non-UTF8 data is not accepted (enabling websockets still enables UTFONLY)
Websocket listeners would process an arbitrary number of invalid
(non-text or blank) messages without throttling. This imposes fakelag
on such messages by treating them as blank lines.