Websocket Support

[GRVYDEV]

Checklist

• [x] I've searched for similar feature requests.

---

Enhancement request

Allow for simple websocket testing

Problem it solves

E.g. “I'm always frustrated when […]”, “I’m trying to do […] so that […]”.

I am building a websocket server and would like an easy way to connect and send messages to it. Nothing too complex.

Basic features would be:

• Sending Messages
• Receiving and displaying messages

---

Additional information, screenshots, or code examples

Here is a link to a website that does something like this https://livepersoninc.github.io/ws-test-page/

…

[arguiot]

Would really need this one too!

[jhwheeler]

This would be fantastic!

[eyayaw]

That would be a great feature. Thank you.

[valentin994]

sounds great, would be willing to help with this if needed

[valentin994]

So I started fiddling with it but I would like some pointers from the maintainer on how they would like this implemented.

The request to send requests isn't hard to implement but there are some ways it could be done. Do we want to implement it in a way where someone could specify the number of messages they want to send, what flags should it support, and what should one showcase after a successful connection, I suppose all headers?

As for receiving messages that would be just opening a connection to the wss and listening for messages?

[arguiot]

I think we should be aiming at something similar to websocat

[valentin994]

Ok, so right now I have a general implementation where you can send one message or multiple messages until you close it with exit().

Example call for now is: https WSS ws://127.0.0.1:8000/ws

Now I would ask for some advice/guideance on how the maintainers would like the implementation to be plugged in.

As for now, I have plugged it in the collect_messages() where I read if the method is WSS and then branch it out to go to a function to create a websocket connection and then another function that reads user input in a while loop sends it and waits for another message until the user types in exit(). In the meantime we have a thread that sends pings to keep the connection alive. Now I would have to implement models and leverage the argsparser better.

The question for now is, do I try to plug it into the present client and request handler or do we separate it as websockets are handled differently anyway.

This is the branch https://github.com/valentin994/cli/tree/websocket-support It is quite crude for now as I am not sure what way we want to go with this.