Customize STOMP ERROR frame [SPR-12732] #17329
The ability to customize which headers are present in the ERROR frame would allow for better front-end handling for error conditions that may have been triggered from ChannelInterceptors.
Currently, if an exception occurs in a channel interceptor (such as if you are attempting to control subscription events based on arbitrary logic), an ERROR frame is sent back to the client from StompSubProtocolHandler.sendErrorMessage.
The ERROR frame simply contains the throwable.getMessage() in a header which causes awkward client side handling.
Could a StompProtocolErrorHandlerStrategy be created to allow for message customization?
Referenced from: pull request #743
Rossen Stoyanchev commented
Seems like a good idea. Exceptions may arise on the inbound and on the outbound sides in the StompSubProtocolHandler resulting in an ERROR frame being sent to the client. Furthermore, an ERROR frame may be sent from StompBrokerRelayMessageHandler for example if the connection is lost or we may even receive an ERROR frame from the broker which we relay back to the client. Providing more insight into what the error represents would be useful.
What kind of customizations do you have in mind? It would probably make sense to have some default implementation.
I have submitted a pull request (#743) with the type of feature that I believe solves this issue. Supplied is a strategy interface, a default implementation for StompSubProtocolHandler and some additional tests.
This covers the feature and allows for configuration BUT, I could not find a decent way to be able to access the StompSubProtocolHandler instance directly from the configuration point of classes extending WebSocketMessageBrokerConfigurationSupport after using
Let me know what you think!