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:
[bug] Sending a request with an infinite handshake request timeout crashes the app #2
[feature] Add ability to name and save requests in a collection #27
[feature] “quicksave” message bodys within a websocket connection that can quickly be sent from the list by just clicking them #29
[feature] Ability to save a list of pre-defined messages to send, with pre-send scripts. #24
[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
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:
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
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.
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”
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.
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?
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
@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:
type in ws://localhost:5555/tk for the URL
click connect
once connected, add you messages in the textarea below and click send
@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.