Expose Websocket close frame when closing from server side

[deep-gaurav]

• I have looked for existing issues (including closed) about this

Feature Request

If I understand correctly, currently we cannot set close reason and code when closing websocket from server side, axum is already exposing CloseCode and CloseFrame for close msg from client side, but we cannot pass it when closing from server.

Motivation

For me i want to reject some websocket connection but websocket spec doest let js get http status code and msg when connect to websocket and failing. Recommended method to do so is to accept connection and immediately close with reason according to https://stackoverflow.com/a/50685387.
Currently I cannot do this. close method does not take any parameters.

Proposal

To maintain backward compatibility we can expose another method, close_with_msg(msg:CloseFrame) which will pass it to tungstenite.

Alternatives

maybe we can do socket.send(axum::extract::ws::Message::Close(())) before calling socket.close() but this seems weird to be, I dont know if sending close frame is also closing connection or not.

[jplatte]

cc @SabrinaJewson

[SabrinaJewson]

You can implement this yourself by sending a close message to the WebSocket.

This issue also caused me to discover that Axum’s current .close() method is incorrect, as it takes ownership of the WebSocket; in reälity, only the write half is closed and for true graceful shutdown one should read more messages from the read half.

I think I’ll make a PR to remove .close() (it’s redundant since you can send close messages) and update the documentation.

[deep-gaurav]

Yeah I did discover that just sending CloseFrame message manually closes the connection. but sending a CloseMessage doesnt take ownership of socket so it's not apparent that it'll also shutdown the websocket connection. Could be just lack of knowledge on my part.

[SabrinaJewson]

but sending a CloseMessage doesnt take ownership of socket so it's not apparent that it'll also shutdown the websocket connection

So this is actually a good thing. The way the WebSocket closing protocol is supposed to work is that:

• Peer A sends the close frame to peer B, does not close the connection, and does not send further frames
• Peer B responds with a close frame, and does not send further frames
• Peer A receives any remaining frames from peer B as well as the close frame
• The connection is finally closed

If close methods take ownership, this protocol is impossible to implement correctly as peer A would not receive the remaining frames from peer B.