I have checked the following:

• I have searched existing issues and found nothing related to my issue.

This bug is:

• making Bruno unusable for me
• slowing me down but I'm able to continue working
• annoying
• this feature was working in a previous version but is broken in the current release.

Bruno version

2.14.2

Operating System

Linux 6.14.0-35-generic

Describe the bug

Related to : issue #5969

STOMP is a very simple messaging protocol that supports real-time updates via WebSockets. When establishing a connection to a STOMP server, the client must:

Send an initial HTTP request granted into a WebSocket connection and
Send a WebSocket message to CONNECT to STOMP server then SUBSCRIBE to topics and listening to messages.

STOMP requires that WebSocket messages end with the \u0000 (NUL) character, as described into STOMP Frames policy. However, it looks like Bruno automatically converts this character into literal \u0000, which breaks the STOMP message format — resulting in no response from the server after having properly initialized the connection, and therefore no subscription are recorded and no message are received from the server. I think it comes from the content type. Currently only TEXT, JSON, XML are available. Binary should solve the problem or at least a Text/Hex editor, or a text editor that interprets \u[CodedChar] characters.

How to reproduce

Set up a STOMP server in Spring boot app (Java), or any other language/app that provide STOMP Server sdk.
Connect to the server using a Bruno websocket connection.
Send the initial CONNECT message to establish a STOMP connection (e.g. 
    ---------- Beginning of message----------------
    CONNECT
    browser-session-id:37737a5c-95d3-4b07-bd4f-d1136fe21056
    accept-version:1.2,1.1,1.0
    heart-beat:10000,10000
    
    ^@
    ---------- End of message, '^@' is Nul char in vim ----------------).
Observe that the server does not respond with a CONNECTED RESPONSE.

Bruno appears to automatically transform characters like \u0000 into literal \u0000 in text editor, preventing proper STOMP message formatting.

Including support for sending raw control characters (such as \u0000) in WebSocket messages should resolve this issue and enable full STOMP compatibility (i think).

.bru file to reproduce the bug

meta {
name: websocket connection
type: ws
seq: 4
}

ws {
url: http://localhost:8098/real-time?token={{access_token}}
body: ws
auth: none
}

body:ws {
name: message 1
content: '''
CONNECT
browser-session-id:[SomeId]
accept-version:1.2,1.1,1.0
heart-beat:10000,10000

\\u0000

'''
}

Screenshots/Live demo link