lib/websocket: reformat comments

Indent comments that reference specifications to differentiate it with the
actual comments for code.

6 files changed, 302 insertions, 310 deletions

diff --git a/lib/websocket/client.go b/lib/websocket/client.go
index 711521b7..f26f9734 100644
--- a/lib/websocket/client.go
+++ b/lib/websocket/client.go
@@ -61,21 +61,21 @@ type Client struct {
 //
 // The endpoint use the following format,
 //
-//```
-// 3.  WebSocket URIs
 //
-//    This specification defines two URI schemes, using the ABNF syntax
-//    defined in RFC 5234 [RFC5234], and terminology and ABNF productions
-//    defined by the URI specification RFC 3986 [RFC3986].
+//	3.  WebSocket URIs
 //
-//      ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
-//      wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
+//	   This specification defines two URI schemes, using the ABNF syntax
+//	   defined in RFC 5234 [RFC5234], and terminology and ABNF productions
+//	   defined by the URI specification RFC 3986 [RFC3986].
 //
-//      ...
+//	     ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
+//	     wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
+//
+//	     ...
+//
+//	   The port component is OPTIONAL; the default for "ws" is port 80,
+//	   while the default for "wss" is port 443.
 //
-//    The port component is OPTIONAL; the default for "ws" is port 80,
-//    while the default for "wss" is port 443.
-//```
 //
 func NewClient(endpoint string, headers http.Header) (cl *Client, err error) {
 	cl = &Client{}
@@ -102,6 +102,7 @@ func NewClient(endpoint string, headers http.Header) (cl *Client, err error) {
 //
 // On success it will set and return server address that can be used on
 // Open().
+//
 // On fail it will return empty server address and error.
 //
 func (cl *Client) ParseURI(endpoint string) (serverAddr string, err error) {
@@ -148,8 +149,8 @@ func GetConnectAddr(u *url.URL) (addr string) {
 
 //
 // Open TCP connection to websocket server address in "host:port" format.
-// If client IsTLS is true, the connection is opened with TLS protocol and the
-// remote name MUST have a valid certificate.
+// If client "IsTLS" field is true, the connection is opened with TLS protocol
+// and the remote name MUST have a valid certificate.
 //
 func (cl *Client) Open(addr string) (err error) {
 	dialer := &net.Dialer{
@@ -177,88 +178,87 @@ func (cl *Client) Open(addr string) (err error) {
 //
 // Handshake send the websocket opening handshake.
 //
-//```RFC6455 P17-P19
-// 1.   The handshake MUST be a valid HTTP request as specified by
-//      [RFC2616].
+//	RFC6455 P17-P19
+//	1.   The handshake MUST be a valid HTTP request as specified by
+//	     [RFC2616].
 //
-// 2.   The method of the request MUST be GET, and the HTTP version MUST
-//      be at least 1.1.
+//	2.   The method of the request MUST be GET, and the HTTP version MUST
+//	     be at least 1.1.
 //
-//      For example, if the WebSocket URI is "ws://example.com/chat",
-//      the first line sent should be "GET /chat HTTP/1.1".
+//	     For example, if the WebSocket URI is "ws://example.com/chat",
+//	     the first line sent should be "GET /chat HTTP/1.1".
 //
-// 3.   The "Request-URI" part of the request MUST match the /resource
-//      name/ defined in Section 3 (a relative URI) or be an absolute
-//      http/https URI that, when parsed, has a /resource name/, /host/,
-//      and /port/ that match the corresponding ws/wss URI.
+//	3.   The "Request-URI" part of the request MUST match the /resource
+//	     name/ defined in Section 3 (a relative URI) or be an absolute
+//	     http/https URI that, when parsed, has a /resource name/, /host/,
+//	     and /port/ that match the corresponding ws/wss URI.
 //
-// 4.   The request MUST contain a |Host| header field whose value
-//      contains /host/ plus optionally ":" followed by /port/ (when not
-//      using the default port).
+//	4.   The request MUST contain a |Host| header field whose value
+//	     contains /host/ plus optionally ":" followed by /port/ (when not
+//	     using the default port).
 //
-// 5.   The request MUST contain an |Upgrade| header field whose value
-//      MUST include the "websocket" keyword.
+//	5.   The request MUST contain an |Upgrade| header field whose value
+//	     MUST include the "websocket" keyword.
 //
-// 6.   The request MUST contain a |Connection| header field whose value
-//      MUST include the "Upgrade" token.
+//	6.   The request MUST contain a |Connection| header field whose value
+//	     MUST include the "Upgrade" token.
 //
-// 7.   The request MUST include a header field with the name
-//      |Sec-WebSocket-Key|.  The value of this header field MUST be a
-//      nonce consisting of a randomly selected 16-byte value that has
-//      been base64-encoded (see Section 4 of [RFC4648]).  The nonce
-//      MUST be selected randomly for each connection.
+//	7.   The request MUST include a header field with the name
+//	     |Sec-WebSocket-Key|.  The value of this header field MUST be a
+//	     nonce consisting of a randomly selected 16-byte value that has
+//	     been base64-encoded (see Section 4 of [RFC4648]).  The nonce
+//	     MUST be selected randomly for each connection.
 //
-//      NOTE: As an example, if the randomly selected value was the
-//      sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
-//      0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header
-//      field would be "AQIDBAUGBwgJCgsMDQ4PEC=="
+//	     NOTE: As an example, if the randomly selected value was the
+//	     sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
+//	     0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header
+//	     field would be "AQIDBAUGBwgJCgsMDQ4PEC=="
 //
-// 8.   The request MUST include a header field with the name |Origin|
-//      [RFC6454] if the request is coming from a browser client.  If
-//      the connection is from a non-browser client, the request MAY
-//      include this header field if the semantics of that client match
-//      the use-case described here for browser clients.  The value of
-//      this header field is the ASCII serialization of origin of the
-//      context in which the code establishing the connection is
-//      running.  See [RFC6454] for the details of how this header field
-//      value is constructed.
+//	8.   The request MUST include a header field with the name |Origin|
+//	     [RFC6454] if the request is coming from a browser client.  If
+//	     the connection is from a non-browser client, the request MAY
+//	     include this header field if the semantics of that client match
+//	     the use-case described here for browser clients.  The value of
+//	     this header field is the ASCII serialization of origin of the
+//	     context in which the code establishing the connection is
+//	     running.  See [RFC6454] for the details of how this header field
+//	     value is constructed.
 //
-//      As an example, if code downloaded from www.example.com attempts
-//      to establish a connection to ww2.example.com, the value of the
-//      header field would be "http://www.example.com".
+//	     As an example, if code downloaded from www.example.com attempts
+//	     to establish a connection to ww2.example.com, the value of the
+//	     header field would be "http://www.example.com".
 //
-// 9.   The request MUST include a header field with the name
-//      |Sec-WebSocket-Version|.  The value of this header field MUST be
-//      13.
+//	9.   The request MUST include a header field with the name
+//	     |Sec-WebSocket-Version|.  The value of this header field MUST be
+//	     13.
 //
-//      NOTE: Although draft versions of this document (-09, -10, -11,
-//      and -12) were posted (they were mostly comprised of editorial
-//      changes and clarifications and not changes to the wire
-//      protocol), values 9, 10, 11, and 12 were not used as valid
-//      values for Sec-WebSocket-Version.  These values were reserved in
-//      the IANA registry but were not and will not be used.
+//	     NOTE: Although draft versions of this document (-09, -10, -11,
+//	     and -12) were posted (they were mostly comprised of editorial
+//	     changes and clarifications and not changes to the wire
+//	     protocol), values 9, 10, 11, and 12 were not used as valid
+//	     values for Sec-WebSocket-Version.  These values were reserved in
+//	     the IANA registry but were not and will not be used.
 //
-// 10.  The request MAY include a header field with the name
-//      |Sec-WebSocket-Protocol|.  If present, this value indicates one
-//      or more comma-separated subprotocol the client wishes to speak,
-//      ordered by preference.  The elements that comprise this value
-//      MUST be non-empty strings with characters in the range U+0021 to
-//      U+007E not including separator characters as defined in
-//      [RFC2616] and MUST all be unique strings.  The ABNF for the
-//      value of this header field is 1#token, where the definitions of
-//      constructs and rules are as given in [RFC2616].
+//	10.  The request MAY include a header field with the name
+//	     |Sec-WebSocket-Protocol|.  If present, this value indicates one
+//	     or more comma-separated subprotocol the client wishes to speak,
+//	     ordered by preference.  The elements that comprise this value
+//	     MUST be non-empty strings with characters in the range U+0021 to
+//	     U+007E not including separator characters as defined in
+//	     [RFC2616] and MUST all be unique strings.  The ABNF for the
+//	     value of this header field is 1#token, where the definitions of
+//	     constructs and rules are as given in [RFC2616].
 //
-// 11.  The request MAY include a header field with the name
-//      |Sec-WebSocket-Extensions|.  If present, this value indicates
-//      the protocol-level extension(s) the client wishes to speak.  The
-//      interpretation and format of this header field is described in
-//      Section 9.1.
+//	11.  The request MAY include a header field with the name
+//	     |Sec-WebSocket-Extensions|.  If present, this value indicates
+//	     the protocol-level extension(s) the client wishes to speak.  The
+//	     interpretation and format of this header field is described in
+//	     Section 9.1.
 //
-// 12.  The request MAY include any other header fields, for example,
-//      cookies [RFC6265] and/or authentication-related header fields
-//      such as the |Authorization| header field [RFC2616], which are
-//      processed according to documents that define them.
-//```
+//	12.  The request MAY include any other header fields, for example,
+//	     cookies [RFC6265] and/or authentication-related header fields
+//	     such as the |Authorization| header field [RFC2616], which are
+//	     processed according to documents that define them.
 //
 func (cl *Client) Handshake(path, origin, proto, ext string, headers http.Header) (err error) {
 	if len(path) == 0 {
diff --git a/lib/websocket/frame.go b/lib/websocket/frame.go
index 55494830..a63eaff1 100644
--- a/lib/websocket/frame.go
+++ b/lib/websocket/frame.go
@@ -40,72 +40,71 @@ const (
 // Status code 1004-1006, and 1015 is reserved and MUST NOT be used on Close
 // payload.
 //
-//```RFC6455 7.4.1-P45
+//	RFC6455 7.4.1-P45
 //
-// 7.4.1.  Defined Status Codes
+//	7.4.1.  Defined Status Codes
 //
-//    Endpoints MAY use the following pre-defined status codes when sending
-//    a Close frame.
+//	Endpoints MAY use the following pre-defined status codes when sending
+//	a Close frame.
 //
-//    1000
+//	1000
 //
-//       1000 indicates a normal closure, meaning that the purpose for
-//       which the connection was established has been fulfilled.
+//	   1000 indicates a normal closure, meaning that the purpose for
+//	   which the connection was established has been fulfilled.
 //
-//    1001
+//	1001
 //
-//       1001 indicates that an endpoint is "going away", such as a server
-//       going down or a browser having navigated away from a page.
+//	   1001 indicates that an endpoint is "going away", such as a server
+//	   going down or a browser having navigated away from a page.
 //
-//    1002
+//	1002
 //
-//       1002 indicates that an endpoint is terminating the connection due
-//       to a protocol error.
+//	   1002 indicates that an endpoint is terminating the connection due
+//	   to a protocol error.
 //
-//    1003
+//	1003
 //
-//       1003 indicates that an endpoint is terminating the connection
-//       because it has received a type of data it cannot accept (e.g., an
-//       endpoint that understands only text data MAY send this if it
-//       receives a binary message).
+//	   1003 indicates that an endpoint is terminating the connection
+//	   because it has received a type of data it cannot accept (e.g., an
+//	   endpoint that understands only text data MAY send this if it
+//	   receives a binary message).
 //
-//    1007
+//	1007
 //
-//       1007 indicates that an endpoint is terminating the connection
-//       because it has received data within a message that was not
-//       consistent with the type of the message (e.g., non-UTF-8 [RFC3629]
-//       data within a text message).
+//	   1007 indicates that an endpoint is terminating the connection
+//	   because it has received data within a message that was not
+//	   consistent with the type of the message (e.g., non-UTF-8 [RFC3629]
+//	   data within a text message).
 //
-//    1008
+//	1008
 //
-//       1008 indicates that an endpoint is terminating the connection
-//       because it has received a message that violates its policy.  This
-//       is a generic status code that can be returned when there is no
-//       other more suitable status code (e.g., 1003 or 1009) or if there
-//       is a need to hide specific details about the policy.
+//	   1008 indicates that an endpoint is terminating the connection
+//	   because it has received a message that violates its policy.  This
+//	   is a generic status code that can be returned when there is no
+//	   other more suitable status code (e.g., 1003 or 1009) or if there
+//	   is a need to hide specific details about the policy.
 //
-//    1009
+//	1009
 //
-//       1009 indicates that an endpoint is terminating the connection
-//       because it has received a message that is too big for it to
-//       process.
+//	   1009 indicates that an endpoint is terminating the connection
+//	   because it has received a message that is too big for it to
+//	   process.
 //
-//    1010
+//	1010
 //
-//       1010 indicates that an endpoint (client) is terminating the
-//       connection because it has expected the server to negotiate one or
-//       more extension, but the server didn't return them in the response
-//       message of the WebSocket handshake.  The list of extensions that
-//       are needed SHOULD appear in the /reason/ part of the Close frame.
-//       Note that this status code is not used by the server, because it
-//       can fail the WebSocket handshake instead.
+//	   1010 indicates that an endpoint (client) is terminating the
+//	   connection because it has expected the server to negotiate one or
+//	   more extension, but the server didn't return them in the response
+//	   message of the WebSocket handshake.  The list of extensions that
+//	   are needed SHOULD appear in the /reason/ part of the Close frame.
+//	   Note that this status code is not used by the server, because it
+//	   can fail the WebSocket handshake instead.
 //
-//    1011
+//	1011
 //
-//       1011 indicates that a server is terminating the connection because
-//       it encountered an unexpected condition that prevented it from
-//       fulfilling the request.
-//```
+//	   1011 indicates that a server is terminating the connection because
+//	   it encountered an unexpected condition that prevented it from
+//	   fulfilling the request.
 //
 var (
 	StatusNormal                = []byte{0x03, 0xE8} // 1000
@@ -130,88 +129,84 @@ var (
 //
 // Frame represent a websocket data protocol.
 //
-//```
-// 5.2 Base Framing Protocol
+//	5.2 Base Framing Protocol
 //
-//    0                   1                   2                   3
-//    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-//   +-+-+-+-+-------+-+-------------+-------------------------------+
-//   |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
-//   |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
-//   |N|V|V|V|       |S|             |   (if payload len==126/127)   |
-//   | |1|2|3|       |K|             |                               |
-//   +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
-//   |     Extended payload length continued, if payload len == 127  |
-//   + - - - - - - - - - - - - - - - +-------------------------------+
-//   |                               |Masking-key, if MASK set to 1  |
-//   +-------------------------------+-------------------------------+
-//   | Masking-key (continued)       |          Payload Data         |
-//   +-------------------------------- - - - - - - - - - - - - - - - +
-//   :                     Payload Data continued ...                :
-//   + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
-//   |                     Payload Data continued ...                |
-//   +---------------------------------------------------------------+
+//	   0                   1                   2                   3
+//	   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+//	  +-+-+-+-+-------+-+-------------+-------------------------------+
+//	  |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
+//	  |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
+//	  |N|V|V|V|       |S|             |   (if payload len==126/127)   |
+//	  | |1|2|3|       |K|             |                               |
+//	  +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
+//	  |     Extended payload length continued, if payload len == 127  |
+//	  + - - - - - - - - - - - - - - - +-------------------------------+
+//	  |                               |Masking-key, if MASK set to 1  |
+//	  +-------------------------------+-------------------------------+
+//	  | Masking-key (continued)       |          Payload Data         |
+//	  +-------------------------------- - - - - - - - - - - - - - - - +
+//	  :                     Payload Data continued ...                :
+//	  + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+//	  |                     Payload Data continued ...                |
+//	  +---------------------------------------------------------------+
 //
-// Mask:  1 bit
+//	Mask:  1 bit
 //
-//    Defines whether the "Payload data" is masked.  If set to 1, a
-//    masking key is present in masking-key, and this is used to unmask
-//    the "Payload data" as per Section 5.3.  All frames sent from
-//    client to server have this bit set to 1.
+//	   Defines whether the "Payload data" is masked.  If set to 1, a
+//	   masking key is present in masking-key, and this is used to unmask
+//	   the "Payload data" as per Section 5.3.  All frames sent from
+//	   client to server have this bit set to 1.
 //
-// Payload length:  7 bits, 7+16 bits, or 7+64 bits
+//	Payload length:  7 bits, 7+16 bits, or 7+64 bits
 //
-//    The length of the "Payload data", in bytes: if 0-125, that is the
-//    payload length.  If 126, the following 2 bytes interpreted as a
-//    16-bit unsigned integer are the payload length.  If 127, the
-//    following 8 bytes interpreted as a 64-bit unsigned integer (the
-//    most significant bit MUST be 0) are the payload length.  Multibyte
-//    length quantities are expressed in network byte order.  Note that
-//    in all cases, the minimal number of bytes MUST be used to encode
-//    the length, for example, the length of a 124-byte-long string
-//    can't be encoded as the sequence 126, 0, 124.  The payload length
-//    is the length of the "Extension data" + the length of the
-//    "Application data".  The length of the "Extension data" may be
-//    zero, in which case the payload length is the length of the
-//    "Application data".
+//	   The length of the "Payload data", in bytes: if 0-125, that is the
+//	   payload length.  If 126, the following 2 bytes interpreted as a
+//	   16-bit unsigned integer are the payload length.  If 127, the
+//	   following 8 bytes interpreted as a 64-bit unsigned integer (the
+//	   most significant bit MUST be 0) are the payload length.  Multibyte
+//	   length quantities are expressed in network byte order.  Note that
+//	   in all cases, the minimal number of bytes MUST be used to encode
+//	   the length, for example, the length of a 124-byte-long string
+//	   can't be encoded as the sequence 126, 0, 124.  The payload length
+//	   is the length of the "Extension data" + the length of the
+//	   "Application data".  The length of the "Extension data" may be
+//	   zero, in which case the payload length is the length of the
+//	   "Application data".
 //
-// Masking-key:  0 or 4 bytes
+//	Masking-key:  0 or 4 bytes
 //
-//    All frames sent from the client to the server are masked by a
-//    32-bit value that is contained within the frame.  This field is
-//    present if the mask bit is set to 1 and is absent if the mask bit
-//    is set to 0.  See Section 5.3 for further information on client-
-//    to-server masking.
+//	   All frames sent from the client to the server are masked by a
+//	   32-bit value that is contained within the frame.  This field is
+//	   present if the mask bit is set to 1 and is absent if the mask bit
+//	   is set to 0.  See Section 5.3 for further information on client-
+//	   to-server masking.
 //
-// Payload data:  (x+y) bytes
+//	Payload data:  (x+y) bytes
 //
-//    The "Payload data" is defined as "Extension data" concatenated
-//    with "Application data".
+//	   The "Payload data" is defined as "Extension data" concatenated
+//	   with "Application data".
 //
-// Extension data:  x bytes
+//	Extension data:  x bytes
 //
-//    The "Extension data" is 0 bytes unless an extension has been
-//    negotiated.  Any extension MUST specify the length of the
-//    "Extension data", or how that length may be calculated, and how
-//    the extension use MUST be negotiated during the opening handshake.
-//    If present, the "Extension data" is included in the total payload
-//    length.
+//	   The "Extension data" is 0 bytes unless an extension has been
+//	   negotiated.  Any extension MUST specify the length of the
+//	   "Extension data", or how that length may be calculated, and how
+//	   the extension use MUST be negotiated during the opening handshake.
+//	   If present, the "Extension data" is included in the total payload
+//	   length.
 //
-// Application data:  y bytes
+//	Application data:  y bytes
 //
-//    Arbitrary "Application data", taking up the remainder of the frame
-//    after any "Extension data".  The length of the "Application data"
-//    is equal to the payload length minus the length of the "Extension
-//    data".
-//```
-//
-// Additional frame field: closeCode.  closeCode represent the
-// status of control frame close request.
+//	   Arbitrary "Application data", taking up the remainder of the frame
+//	   after any "Extension data".  The length of the "Application data"
+//	   is equal to the payload length minus the length of the "Extension
+//	   data".
 //
 type Frame struct {
-	Fin       byte
-	Opcode    byte
-	Masked    byte
+	Fin    byte
+	Opcode byte
+	Masked byte
+	// closeCode represent the status of control frame close request.
 	closeCode uint16
 	len       uint64
 	maskKey   [4]byte
@@ -221,17 +216,16 @@ type Frame struct {
 //
 // unpack websocket data protocol from raw bytes to single frame.
 //
-//```RFC6455
-// (5.4-P33)
-// o  Control frames (see Section 5.5) MAY be injected in the middle of a
-//    fragmented message.  Control frames themselves MUST NOT be
-//    fragmented.
+//	RFC6455
+//	(5.4-P33)
+//	o  Control frames (see Section 5.5) MAY be injected in the middle of a
+//	   fragmented message.  Control frames themselves MUST NOT be
+//	   fragmented.
 //
-// (5.5-P36)
-// All control frames MUST have a payload length of 125 bytes or less
-// and MUST NOT be fragmented.
+//	(5.5-P36)
+//	All control frames MUST have a payload length of 125 bytes or less
+//	and MUST NOT be fragmented.
 //
-//```
 //
 // On success it will return non nil frame.  It is the responsibility of the
 // caller to handle continuation frames.
@@ -345,9 +339,8 @@ func Unpack(in []byte) (fs []*Frame) {
 // Frame maskKey will be set randomly only if Masked is set and randomMask
 // parameter is true.
 //
-//```RFC6455 5.1-P27
-// A server MUST NOT mask any frames that it sends to the client.
-//```
+//	RFC6455 5.1-P27
+//	A server MUST NOT mask any frames that it sends to the client.
 //
 func (f *Frame) Pack(randomMask bool) (out []byte) {
 	headerSize := uint64(2)
diff --git a/lib/websocket/handshake.go b/lib/websocket/handshake.go
index 43abb76c..77133e9b 100644
--- a/lib/websocket/handshake.go
+++ b/lib/websocket/handshake.go
@@ -43,10 +43,9 @@ var (
 )
 
 //
-//```RFC6455 4.1 P20
-// Please note that according to [RFC2616], all header field names in
-// both HTTP requests and HTTP responses are case-insensitive.
-//```
+//	RFC6455 4.1 P20
+//	Please note that according to [RFC2616], all header field names in
+//	both HTTP requests and HTTP responses are case-insensitive.
 //
 var (
 	_hdrKeyConnection        = "connection"
@@ -222,93 +221,92 @@ func (h *Handshake) headerValueContains(hv, sub []byte) bool {
 //
 // Parse HTTP request.
 //
-//```RFC6455 4.1-P17-19
+//	RFC6455 4.1-P17-19
 //
-// 1.   The handshake MUST be a valid HTTP request as specified by
-//      [RFC2616].
+//	1.   The handshake MUST be a valid HTTP request as specified by
+//	     [RFC2616].
 //
-// 2.   The method of the request MUST be GET, and the HTTP version MUST
-//      be at least 1.1.
+//	2.   The method of the request MUST be GET, and the HTTP version MUST
+//	     be at least 1.1.
 //
-//      For example, if the WebSocket URI is "ws://example.com/chat",
-//      the first line sent should be "GET /chat HTTP/1.1".
+//	     For example, if the WebSocket URI is "ws://example.com/chat",
+//	     the first line sent should be "GET /chat HTTP/1.1".
 //
-// 3.   The "Request-URI" part of the request MUST match the /resource
-//      name/ defined in Section 3 (a relative URI) or be an absolute
-//      http/https URI that, when parsed, has a /resource name/, /host/,
-//      and /port/ that match the corresponding ws/wss URI.
+//	3.   The "Request-URI" part of the request MUST match the /resource
+//	     name/ defined in Section 3 (a relative URI) or be an absolute
+//	     http/https URI that, when parsed, has a /resource name/, /host/,
+//	     and /port/ that match the corresponding ws/wss URI.
 //
-// 4.   The request MUST contain a |Host| header field whose value
-//      contains /host/ plus optionally ":" followed by /port/ (when not
-//      using the default port).
+//	4.   The request MUST contain a |Host| header field whose value
+//	     contains /host/ plus optionally ":" followed by /port/ (when not
+//	     using the default port).
 //
-// 5.   The request MUST contain an |Upgrade| header field whose value
-//      MUST include the "websocket" keyword.
+//	5.   The request MUST contain an |Upgrade| header field whose value
+//	     MUST include the "websocket" keyword.
 //
-// 6.   The request MUST contain a |Connection| header field whose value
-//      MUST include the "Upgrade" token.
+//	6.   The request MUST contain a |Connection| header field whose value
+//	     MUST include the "Upgrade" token.
 //
-// 7.   The request MUST include a header field with the name
-//      |Sec-WebSocket-Key|.  The value of this header field MUST be a
-//      nonce consisting of a randomly selected 16-byte value that has
-//      been base64-encoded (see Section 4 of [RFC4648]).  The nonce
-//      MUST be selected randomly for each connection.
+//	7.   The request MUST include a header field with the name
+//	     |Sec-WebSocket-Key|.  The value of this header field MUST be a
+//	     nonce consisting of a randomly selected 16-byte value that has
+//	     been base64-encoded (see Section 4 of [RFC4648]).  The nonce
+//	     MUST be selected randomly for each connection.
 //
-//      NOTE: As an example, if the randomly selected value was the
-//      sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
-//      0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header
-//      field would be "AQIDBAUGBwgJCgsMDQ4PEC=="
+//	     NOTE: As an example, if the randomly selected value was the
+//	     sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
+//	     0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header
+//	     field would be "AQIDBAUGBwgJCgsMDQ4PEC=="
 //
-//      ...
-//      The |Sec-WebSocket-Key| header field MUST NOT appear more than once
-//      in an HTTP request.
+//	     ...
+//	     The |Sec-WebSocket-Key| header field MUST NOT appear more than once
+//	     in an HTTP request.
 //
-// 8.   The request MUST include a header field with the name |Origin|
-//      [RFC6454] if the request is coming from a browser client.  If
-//      the connection is from a non-browser client, the request MAY
-//      include this header field if the semantics of that client match
-//      the use-case described here for browser clients.  The value of
-//      this header field is the ASCII serialization of origin of the
-//      context in which the code establishing the connection is
-//      running.  See [RFC6454] for the details of how this header field
-//      value is constructed.
+//	8.   The request MUST include a header field with the name |Origin|
+//	     [RFC6454] if the request is coming from a browser client.  If
+//	     the connection is from a non-browser client, the request MAY
+//	     include this header field if the semantics of that client match
+//	     the use-case described here for browser clients.  The value of
+//	     this header field is the ASCII serialization of origin of the
+//	     context in which the code establishing the connection is
+//	     running.  See [RFC6454] for the details of how this header field
+//	     value is constructed.
 //
-//      As an example, if code downloaded from www.example.com attempts
-//      to establish a connection to ww2.example.com, the value of the
-//      header field would be "http://www.example.com".
+//	     As an example, if code downloaded from www.example.com attempts
+//	     to establish a connection to ww2.example.com, the value of the
+//	     header field would be "http://www.example.com".
 //
-// 9.   The request MUST include a header field with the name
-//      |Sec-WebSocket-Version|.  The value of this header field MUST be
-//      13.
+//	9.   The request MUST include a header field with the name
+//	     |Sec-WebSocket-Version|.  The value of this header field MUST be
+//	     13.
 //
-//      NOTE: Although draft versions of this document (-09, -10, -11,
-//      and -12) were posted (they were mostly comprised of editorial
-//      changes and clarifications and not changes to the wire
-//      protocol), values 9, 10, 11, and 12 were not used as valid
-//      values for Sec-WebSocket-Version.  These values were reserved in
-//      the IANA registry but were not and will not be used.
+//	     NOTE: Although draft versions of this document (-09, -10, -11,
+//	     and -12) were posted (they were mostly comprised of editorial
+//	     changes and clarifications and not changes to the wire
+//	     protocol), values 9, 10, 11, and 12 were not used as valid
+//	     values for Sec-WebSocket-Version.  These values were reserved in
+//	     the IANA registry but were not and will not be used.
 //
-// 10.  The request MAY include a header field with the name
-//      |Sec-WebSocket-Protocol|.  If present, this value indicates one
-//      or more comma-separated subprotocol the client wishes to speak,
-//      ordered by preference.  The elements that comprise this value
-//      MUST be non-empty strings with characters in the range U+0021 to
-//      U+007E not including separator characters as defined in
-//      [RFC2616] and MUST all be unique strings.  The ABNF for the
-//      value of this header field is 1#token, where the definitions of
-//      constructs and rules are as given in [RFC2616].
+//	10.  The request MAY include a header field with the name
+//	     |Sec-WebSocket-Protocol|.  If present, this value indicates one
+//	     or more comma-separated subprotocol the client wishes to speak,
+//	     ordered by preference.  The elements that comprise this value
+//	     MUST be non-empty strings with characters in the range U+0021 to
+//	     U+007E not including separator characters as defined in
+//	     [RFC2616] and MUST all be unique strings.  The ABNF for the
+//	     value of this header field is 1#token, where the definitions of
+//	     constructs and rules are as given in [RFC2616].
 //
-// 11.  The request MAY include a header field with the name
-//      |Sec-WebSocket-Extensions|.  If present, this value indicates
-//      the protocol-level extension(s) the client wishes to speak.  The
-//      interpretation and format of this header field is described in
-//      Section 9.1.
+//	11.  The request MAY include a header field with the name
+//	     |Sec-WebSocket-Extensions|.  If present, this value indicates
+//	     the protocol-level extension(s) the client wishes to speak.  The
+//	     interpretation and format of this header field is described in
+//	     Section 9.1.
 //
-// 12.  The request MAY include any other header fields, for example,
-//      cookies [RFC6265] and/or authentication-related header fields
-//      such as the |Authorization| header field [RFC2616], which are
-//      processed according to documents that define them.
-//```
+//	12.  The request MAY include any other header fields, for example,
+//	     cookies [RFC6265] and/or authentication-related header fields
+//	     such as the |Authorization| header field [RFC2616], which are
+//	     processed according to documents that define them.
 //
 // Based on above requirements, the minimum handshake header is,
 //
diff --git a/lib/websocket/server.go b/lib/websocket/server.go
index 2d29e5a5..4b7abfee 100644
--- a/lib/websocket/server.go
+++ b/lib/websocket/server.go
@@ -269,29 +269,28 @@ func (serv *Server) upgrader() {
 //
 // handleFragment will handle continuation frame (fragmentation).
 //
-//```
-// (5.4-P34)
-// o  A fragmented message consists of a single frame with the FIN bit
-//    clear and an opcode other than 0, followed by zero or more frames
-//    with the FIN bit clear and the opcode set to 0, and terminated by
-//    a single frame with the FIN bit set and an opcode of 0.  A
-//    fragmented message is conceptually equivalent to a single larger
-//    message whose payload is equal to the concatenation of the
-//    payloads of the fragments in order; however, in the presence of
-//    extensions, this may not hold true as the extension defines the
-//    interpretation of the "Extension data" present.  For instance,
-//    "Extension data" may only be present at the beginning of the first
-//    fragment and apply to subsequent fragments, or there may be
-//    "Extension data" present in each of the fragments that applies
-//    only to that particular fragment.  In the absence of "Extension
-//    data", the following example demonstrates how fragmentation works.
 //
-//    EXAMPLE: For a text message sent as three fragments, the first
-//    fragment would have an opcode of 0x1 and a FIN bit clear, the
-//    second fragment would have an opcode of 0x0 and a FIN bit clear,
-//    and the third fragment would have an opcode of 0x0 and a FIN bit
-//    that is set.
-//```
+//	(5.4-P34)
+//	o  A fragmented message consists of a single frame with the FIN bit
+//	   clear and an opcode other than 0, followed by zero or more frames
+//	   with the FIN bit clear and the opcode set to 0, and terminated by
+//	   a single frame with the FIN bit set and an opcode of 0.  A
+//	   fragmented message is conceptually equivalent to a single larger
+//	   message whose payload is equal to the concatenation of the
+//	   payloads of the fragments in order; however, in the presence of
+//	   extensions, this may not hold true as the extension defines the
+//	   interpretation of the "Extension data" present.  For instance,
+//	   "Extension data" may only be present at the beginning of the first
+//	   fragment and apply to subsequent fragments, or there may be
+//	   "Extension data" present in each of the fragments that applies
+//	   only to that particular fragment.  In the absence of "Extension
+//	   data", the following example demonstrates how fragmentation works.
+//
+//	   EXAMPLE: For a text message sent as three fragments, the first
+//	   fragment would have an opcode of 0x1 and a FIN bit clear, the
+//	   second fragment would have an opcode of 0x0 and a FIN bit clear,
+//	   and the third fragment would have an opcode of 0x0 and a FIN bit
+//	   that is set.
 //
 // The first frame and their continuation is saved on map of socket connection
 // and frame: fragments.
@@ -303,10 +302,12 @@ func (serv *Server) upgrader() {
 // request will replace any previous non-completed fragmentation.
 //
 // (2) request is the middle frame (fin = 0 && opcode = 0).
+//
 // (2.1) Check if previous fragmentation exists, if not ignore the request.
 // (2.2) Append the request payload with previous frame.
 //
 // (3) request is the last frame (fin = 1 && opcode = 0)
+//
 // (3.1) Check if previous fragmentation exists, if not ignore the request.
 // (3.2) Append the request payload with previous frame.
 // (3.3) Handle request
diff --git a/lib/websocket/usersockets.go b/lib/websocket/usersockets.go
index d66790ff..4b413c91 100644
--- a/lib/websocket/usersockets.go
+++ b/lib/websocket/usersockets.go
@@ -21,8 +21,8 @@ type UserSockets struct {
 }
 
 //
-// Add append new socket `conn` to user ID uid only if the socket is not
-// already exist.
+// Add new socket connection to user ID only if the socket is not already
+// exist.
 //
 func (us *UserSockets) Add(uid uint64, conn int) {
 	v, ok := us.Load(uid)
diff --git a/lib/websocket/websocket.go b/lib/websocket/websocket.go
index 81b4e81f..b500b8f8 100644
--- a/lib/websocket/websocket.go
+++ b/lib/websocket/websocket.go
@@ -9,11 +9,11 @@
 // The websocket server is implemented with epoll [3], which means it's only
 // run on Linux.
 //
-// # Constraints
+// Constraints
 //
-// * Routing is handled by proxy layer (e.g. haproxy).
+// Routing is handled by proxy layer (e.g. HAProxy).
 //
-// # References
+// References
 //
 // [1] https://tools.ietf.org/html/rfc6455
 //
@@ -60,7 +60,7 @@ var (
 )
 
 //
-// Recv all content from file descriptor into slice of bytes.
+// Recv read all content from file descriptor into slice of bytes.
 //
 // On success it will return buffer from pool. Caller must put the buffer back
 // to the pool.
@@ -137,8 +137,8 @@ func SendFrame(fd int, f *Frame, randomMask bool) (err error) {
 }
 
 //
-// GenerateHandshakeKey generate a randomly selected 16-byte value that has
-// been base64-encoded (see Section 4 of [RFC4648]).
+// GenerateHandshakeKey randomly selected 16-byte value that has been
+// base64-encoded (see Section 4 of [RFC4648]).
 //
 func GenerateHandshakeKey() (key []byte) {
 	if _rng == nil {
@@ -158,7 +158,7 @@ func GenerateHandshakeKey() (key []byte) {
 
 //
 // GenerateHandshakeAccept generate server accept key by concatenating key,
-// defined above in step 4 in Section 4.2.2, with the string
+// defined in step 4 in Section 4.2.2, with the string
 // "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this
 // concatenated value to obtain a 20-byte value and base64-encoding (see
 // Section 4 of [RFC4648]) this 20-byte hash.