Providing a reason in CloseStatus gives a better understanding of the root cause on the WebSocket client side.
Comment From: zhmaeff
Hi @rstoyanchev , could you pls review it?
Comment From: zhmaeff
Yes, providing a reason would be useful. My one concern would be to expose information to external clients that reveals the server being used. In that sense the response status isn't meant to be for debugging but more of a hint for what happened. Perhaps we could choose a a fixed reason for this case that is a bit more helpful than just the status code?
Hi @rstoyanchev , do you mean the same reason for both send time limit exceeded AND the buffer size limit exceeded cases?
Current impl contains the following possible reasons:
Send time x (ms) for session 'y' exceeded the allowed limit z
Buffer size x bytes for session 'y' exceeds the allowed limit z
Would reason like this be acceptable? It hides session ids, current config values but still hints possible issues.
Send time or buffer size limit exceeded
Comment From: rstoyanchev
Something like that, perhaps we can say "Failed to send message within the configured send limit". After all, it's hard to say whether it took too long because the network is slow, or because too many messages are sent, or combination of both. We just know that the send throughput cannot be sustained.
Comment From: zhmaeff
@rstoyanchev updated according to your suggestion