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.
According to the de facto standard, `AWAY :\r\n` is equivalent to `AWAY\r\n`.
Our behavior was inconsistent before, now it consistently matches the de facto
standard.
See 69448b13a1 / #1969; the compiler can now ensure that a uint64
intended for atomic access is always aligned to a 64-bit boundary.
Convert atomic operations on uint32s and pointers as well.
On a 32-bit architecture, 64-bit atomic loads and stores must be aligned to a
64-bit boundary. Since the (mysql.MySQL) struct is directly included in the
Server struct, it is impossible to guarantee this via the standard technique
of putting the 64-bit value at the beginning of the struct definition
(since the point at which it is included in the parent struct may cross a
64-bit boundary).
This optimization is probably pointless anyway, adding an additional
indirection won't make a difference.
NS SAREGISTER should send machine-readable responses. A simple approach:
check if the account-registration cap is enabled, and if so, send the
the same responses that would be sent by the REGISTER command.