Based on the WebSocket Protocol spec (https://websockets.spec.whatwg.org/ and https://datatracker.ietf.org/doc/html/rfc6455), the specific errors listed in the WebSocketObserver are not allowed. Only the following notifications are provided:

• Open - the socket was opened successfully; the WebSocket extensions and protocol in use can be provided via this callback, since they are typically available from the WebSocket component after the socket has been opened
• Error - an error occurred during the connection; there typically isn't any additional information included with this notification since the Close notification provides specific details regarding why the connection was closed
• Message - binary or text data was received from the WebSocket
• Close - the socket was closed; values provided include the wasClean, the WebSocket connection close code, and a text string based reason

The WebSocketObserver interface and corresponding ClientImpl::Connection (which implements the WebSocketObserver) will need to be updated to support these specific notifications. These changes may also need to be propagated to the test Server.

Based on these changes, Connection will need to perform the following actions when a WebSocket status code 1006 (abnormal close) takes place:
1. Attempt to request an access token:

• If the access token request is successful, try to reconnect with the new access token
• if the access token request is successful and a redirect occurred, provide the new access token and web address to connect
• If the access token request is unsuccessful, log out the user
  2. Attempt to connect to the websocket again with the updated access token (and web address if a redirect occurred)
  3. If the second attempt fails, hold off and attempt to connect to the server at a later time (e.g. via Connection's current initiate_reconnect_wait())

Some WebSocket implementations may provide the HTTP status code as part of the reason string, so it could be possible to infer the reason of the error and react accordingly - this will need to be investigated as part of these changes, or create a separate ticket to handle this.

The following WebSocket error codes will be provided and can be handled appropriately:

• 1000 - normal close
• 1001 - connection or endpoint is "going away"
• 1002 - protocol error
• 1003 - unsupported data
• 1007 - invalid frame payload data
• 1008 - policy violation
• 1009 - message too big
• 1011 - internal server error

The following errors will/should not be received, and should be treated as a generic abnormal closure (1006):

• 1004 - reserved
• 1005 - no status code present
• 1015 - TLS handshake error (not supported by WebSocket implementations and likely an invalid server response)