hashrocket/ws

websocket command line tool

ws

ws is a simple command line websocket client designed for exploring and debugging websocket servers. ws includes readline-style keyboard shortcuts, persistent history, and colorization.

Installation

go get -u github.com/hashrocket/ws

Usage

Simply run ws with the destination URL. For security some sites check the origin header. ws will automatically send the destination URL as the origin. If this doesn't work you can specify it directly with the --origin parameter.

$ ws ws://localhost:3000/ws
> {"type": "echo", "payload": "Hello, world"}
< {"type":"echo","payload":"Hello, world"}
> {"type": "broadcast", "payload": "Hello, world"}
< {"type":"broadcast","payload":"Hello, world"}
< {"type":"broadcastResult","payload":"Hello, world","listenerCount":1}
> ^D
EOF

ws's Issues

Cant read redirected STDIN

first of, great program.
But i have an issue trying to redirect commands stored in files.
./ws wss://servername < file
causes EOF message end exit.
However stdout redirection works allright and i can ./ws servername > file without any issues (other than blindtyping commands).

Ubuntu 16.04 but same issue occurs on Debian 8

Accept plain old http[s] scheme

Please let users input WebSocket URL's as http / https, since that's how WebSocket addresses are actually served and used.

Verbose mode?

Hi,

I've just downloaded ws to try debugging a problematic service with it, and it looks like there's something fundamentally wrong with the setup:

ws ws://example.com/

websocket: bad handshake

However, that's as much as I can get from ws. Could you please consider a typical --verbose or -d/--debug switch so that ws would dump all it knows about the connection in such cases? Thanks, and keep up the good work!

Messed up color codes

ws does not appear to register a proper signal handler, so when the application is terminated with SIGINT, then ws often fails to restore the color codes back to normal on exit.

As a workaround, I keep having to explicitly call bash's reset command.

Ability to send additional headers with requests

Hi,

I am trying to test an authenticated websocket endpoint using this tool. To do this I need to send an Authorization header to the endpoint so it can authenticate my connection. Unfortunately, I have no way to do this with this tool. I saw that you already have a flag to set the Origin header - would it be possible to allow users to set arbitrary headers, like curl does?

Thank you!

• Andi

Binaries in Release?

I would love to be able to pull this into my tooling, for example in dockerfiles.

Would you be able to add binaries to the releases?

not working

with:

Linux ubntvm 4.15.0-34-generic #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
@ubntvm:$ go get -v -u github.com/hashrocket/ws
github.com/hashrocket/ws (download)
@ubntvm:$ ws
ws: command not found
@ubntvm:~$

Binary mode

Currently all packets are sent with text mode. It would be nice to be able to either specify the opcode (refer to here), or have a --bin option to send just send the opcode 2 instead.

Missing CloseMessage event

I think this should send a CloseMessage frame before closing the connection, rather than just sending an EOF as at the moment. I think s.ws.WriteMessage(websocket.CloseMessage, []byte{}) in the error handling part of readConsole would do this, but my go isn't good enough for me to be sure.