User Feedback - WebSocket support

Hey everyone! :wave:

We’ve just released support for WebSocket request (beta) in Postman v8.5.0, if you haven’t tried it yet check out our blog post and give it a go!

We’ll be using this thread to centralise any feedback you may have on the feature. This will help us ensure that we’re heading the right way as we move towards the next steps in supporting WebSockets in Postman.

Feedback:

  • :white_check_mark: [bug] Sending a request with an infinite handshake request timeout crashes the app #2
  • :white_check_mark: [feature] Add ability to name and save requests in a collection #27
  • :white_check_mark: [feature] “quicksave” message bodys within a websocket connection that can quickly be sent from the list by just clicking them #29
  • :white_check_mark: [feature] Ability to save a list of pre-defined messages to send, with pre-send scripts. #24
  • [feature] case/regex matching for the search #2 - filed on GitHub here
  • [feature] add ability to configure client certificate to the “Settings” tab #7
  • [feature] support enabling configurable client-side pings in the settings (e.g. ping every 10s) #22, #43
  • [feature] schedule recurring messages over the websocket #22
  • [feature] Use the same cookies as in the HTTP requests. So I could, for example, log in a server via an HTTP auth request and then connect to the websocket in the same session. #24
  • [feature] Test scripts for executing after receiving messages. #24
  • [feature] Two-pane view support. Messages at the right and everything else on the left. #24
  • [feature] Reverse order of messages (new messages at the bottom) #25
  • [feature] Be able to define variables within the request scope - like regular http requests #27
  • [feature] Integrated SignalR websocket support #28
  • [feature] Automatic authorization handling similar to existing functionality http header. #28
  • [feature] Allow to create websocket requests in scratchpad mode
16 Likes

I know what I like, and I like what I see! :clap: :clap:

In the interests of being the first to report a bug (because that’s what I do for a living), there aren’t any upper bounds to the Settings values, and if you type enough digits then it ends up displaying as Infinity:

infinity

Postman crashes if you try to submit with this value. But now I have a way to reliably crash Postman if I want; which, as a tester, maybe I do :sweat_smile:

Feedback #2: The search/filter in the message pane is excellent :chefs-kiss: but would be even better if it could be given the same power as the other search fields in Postman, i.e. case/regex matching.

9 Likes

To infinity and… not beyond! :grinning_face_with_smiling_eyes: Good catch @neilstudd, adding to the list!

1 Like

Thanks a lot for bringing this feature to Postman. It is not working with Sec-WebSocket-Protocol request, the handshake itself fails as “Server sent a subprotocol but none was requested” but the same works with other browser extensions like “WebSocket king client”

3 Likes

@kranthikumarkvs Thanks for reporting this issue.
Can you share the Sec-WebSocket-Protocol value? Also, is this API publicly accessible?

1 Like

No, it is private API.

Sec-WebSocket-Protocol: jwt, eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9FdktfT1

The value after comma is application specific access token.

1 Like

Would you please add ability to configure client certificate to the “Settings” tab.
Thank you.

2 Likes

Yes! :100:
Thanks for the feedback @mbelmont.

1 Like

I have a C# .Net Core 5 WebSocket server using the websocket-sharp nuget package.
I have a C# client successfully sending and receiving websocket messages to the server.

On the Client in C#

public MainWindow()
{
    InitializeComponent();
    ws = new WebSocket("ws://localhost:5555/tk");
    ws.OnMessage += (sender, e) =>
        Debug.WriteLine("Laputa says: " + e.Data);
}

WebSocket ws;
private void Button_Click(object sender, RoutedEventArgs e)
{
ws.Connect();
ws.Send("BALUS");
}

and I receive the message from the server.

In Postman, I set my uri to
ws://localhost:5555/tk

my Params as BALUS

When I click Connect I see

Could not connect to ws://localhost:5555/tk

14:31:45

Error: connect ECONNREFUSED 127.0.0.1:5555

Handshake Details

Request URL: http://localhost:5555/tk

Request Method: GET

:arrow_forward:Request Headers

Sec-WebSocket-Version: 13

Sec-WebSocket-Key: 12W0zUUjJ9Tzl/rWlBr3dA==

Connection: Upgrade

Upgrade: websocket

Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

Host: “localhost:5555”

I’m v new to websockets and the c# library I’m using, so might well be missing something obvious, but the fact that the client in C# works makes me wonder what that could be?

Hey @mailmaxxx

Could you confirm which platform you’re using - The native Postman App or the Web Version?

If you’re using the Web Version, do you have the latest Postman Agent installed and have that selected in the UI?

You may have Auto Select enabled which might be pointing to the Cloud Agent, you can check this in the UI, on the menu bar at the bottom right of the view.

A screenshot of the full app view will also help us to know what’s happening in front of you :grin:

Hi, I have the same issue here when using wamp.2.json subprotocol.

**Error:** Server sent a subprotocol but none was requested
###### Handshake Details
Request URL: http://localhost:18080/ws
Request Method: GET
Status Code: 101 Switching Protocols
â–¶Request Headers
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: aigFfMpXIPIiw2E4eCj5EQ==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Protocol: wamp.2.json
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: localhost:18080
â–¶Response Headers
connection: Upgrade
date: Sat, 22 May 2021 12:13:57 GMT
sec-websocket-accept: c6V1UOcL4RolRReq9QWCaZUzS4U=
sec-websocket-extensions: permessage-deflate; server_max_window_bits=11; client_max_window_bits=11
sec-websocket-protocol: wamp.2.json
server: Cowboy
upgrade: websocket

I am using the desktop client on the macos, updated today

@mailmaxxx It looks like you’re trying to send BALUS as a URL parameter when creating the connection. You need to first connect to your WebSocket endpoint, then you can send messages:

  1. type in ws://localhost:5555/tk for the URL
  2. click connect
  3. once connected, add you messages in the textarea below and click send

ws-connect-send

Let us know if that helps!

1 Like

@arlem In my case I am not sending any param and properly requesting the WAMP subprotocol. The WAMP router replies with the subprotocol requested but Postman fails as if I never requested it. Any ideas?

@aramallo My guess is that we’re not supporting that sub-protocol yet, but I’ll leave it to the engineering team to confirm! If we don’t support it I’ll add it as a feature request.

1 Like

Thanks Fantastic…Notice there is wamp.2.msgpack too if you can add it :slight_smile:

@kranthikumarkvs Can you try setting the Sec-WebSocket-Protocol header with the expected value?

I am also having trouble getting this set up.

basically - I’m suck trying to connect to a local host running socket.io

const port =5001;

io.on("connection", (socket) => {
  socket.emit("handshake","connected to backend");
  socket.on("test", (data)=>{
    console.log("test data is:",data);
    socket.emit("test", "server heard you!")
  });

and the request url is:

ws://localhost:5001/socket.io/
//wss doesn't work either

which results in

Error: Unexpected server response: 400 //for ws


Error: write EPROTO 132740312:error:100000f7:SSL 

I don’t have anything other than a default install of nodejs/socket.io - is the above the correct url format?

@udit, still the same issue use secure header -

Error: Server sent a subprotocol but none was requested

Does it show binary data coming via the socket?

Hey @abhi-varma202!

Yes, you can :slightly_smiling_face: !

For cases where the binary data is a Media message (image/audio/video), you will be able to view it as it is.

For rest of the scenarios, you can view the hex dump of your binary messages.

Alternatively, you can also try the Show Message option on the top right corner of the message to perceive the binary data as string.