2 extra bytes are sent on close()

The frame that is sent by the WebSocket->close() function contains a total of 4 bytes. 0x88 0x00 0x00 0x00 . 0x88 is the correct heading byte for a close connection message. 0x00 denotes a non-masked message of application-data size 0 therefore, the two following bytes shouldn't be there because the data size is defined as 0. They are interpreted (by wireshark) as a continuation unmasked frame of size 0 (which is against the RFC6455 bit "The application MUST NOT send any more data frames after sending a Close frame.").

Such specification states also that there may be some application data in a closing frame, but it should be formatted as described: " The Close frame MAY contain a body (the "Application data" portion of the frame) that indicates a reason for closing, such as an endpoint shutting down, an endpoint having received a frame too large, or an endpoint having received a frame that does not conform to the format expected by the endpoint. If there is a body, the first two bytes of the body MUST be a 2-byte unsigned integer (in network byte order) representing a status code with value /code/ defined in Section 7.4. Following the 2-byte integer, the body MAY contain UTF-8-encoded data with value /reason/, the interpretation of which is not defined by this specification. This data is not necessarily human readable but may be useful for debugging or passing information relevant to the script that opened the connection. As the data is not guaranteed to be human readable, clients MUST NOT show it to end users." (RFC 6455)

Furthermore, even though it may sound strange: " Close frames sent from client to server must be masked" (RFC 6455)

Implementing all of these specifications is easy and would give us a more standard-compliant platform.

dhbaird / easywsclient

2 extra bytes are sent on close() #21