SeeWebSocket specs 7.4.1

1006 is a reserved value and MUST NOT be set as a status code in a Close control frame by an endpoint. It is designated for use in applications expecting a status code to indicate that the connection was closed abnormally, e.g., without sending or receiving a Close control frame.

Also7.1.5

IfThe WebSocket Connection is Closed and no Close control frame was received by the endpoint (such as could occur if the underlying transport connection is lost),The WebSocket Connection Close Code is considered to be 1006.

And11.7

-+------------+-----------------+---------------+------------------------------------------------------------| | 1006       | Abnormal Closure| hybi@ietf.org | [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455)  |-+------------+-----------------+---------------+------------------------------------------------------------|

The problem is right now the app only gets a status code if the connection gets closed correctly, triggered by the client. (If user code triggers closing, no status code will be send to the app which is OK).

However, if a WebSocket connection is lost / abnormaly closed, for whatever reason (network is down, cable unplugged, ...), currently the app does not receive a close message, but according to the specs this is what 1006 is for.

Currently, one can only detect if a connection is closed via watchTermination on a flow like (java code):

Flow.fromSinkAndSource(someSink,someSource).watchTermination((prevMatValue,completionStage) -> {// This function will be run when the stream terminates// the CompletionStage provided as a second parameter indicates whether// the stream completed successfully or failedcompletionStage.whenComplete((done,exc) -> {if (done !=null) {// For Play WebSockets, we -->always<-- enter this if condition, even when the connection was closed abnormallySystem.out.println("The stream materialized successfully " +prevMatValue.toString());      }else {System.out.println(exc.getMessage());      }    });returnprevMatValue;});

As you see from this code, the watchtermination is always called in a way so that done is set, no matter what the reason is that a connections got closed: you can not determine the connection was closed cleanly (triggered by user code or by the client) or if the connection was closed abnormally. There is only one work around I can think of currently, which would be to capture the close status code of a close message, if one is received, and check in the watch termination if there was a close message before, and if so one knows if the connection was closed clean or not (also the user needs to save if the connection was closed by user code of course to make the distinction).

With this PR I always make the WebSocket send a close status code to the user code with status 1006 if the connection is not closed cleanly by user code nor by the client.