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.13.2

Operating System

Windows 11 22631.6060

Describe the bug

SignalR is a .NET library that supports real-time updates via WebSockets. When establishing a connection to a SignalR hub, the client must:

1. Send an initial WebSocket request, and
2. Send a WebSocket message specifying the protocol to use.

SignalR requires that WebSocket messages end with the \u001E (record separator) character. However, it looks like Bruno automatically converts this character into \u0001, which breaks the SignalR connection setup — resulting in no response from the hub after the initial protocol message, and therefore closes the connection, after a couple of seconds.

How to reproduce

1. Set up a SignalR hub in a .NET application.
2. Run a negotiate call to your hub endpoint (e.g., /hub/negotiate).
3. Connect to the returned WebSocket endpoint.
4. Send the initial message to set the protocol before you get disconnected (e.g., {"protocol":"json","version":1}\u001E).
5. Observe that the server does not respond.

Bruno appears to automatically transform control characters like \u001E into \u0001, preventing proper SignalR message formatting.

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

.bru file to reproduce the bug

No response

Screenshots/Live demo link

The image here shows the flow 1. successfully connected to my hub endpoint 2. i sent the protocol message, without getting a response 3. the server closes the connection