All sections

Protocols

WebSocket

On this page

A WebSocket tab in Tetiva is an address, a Connect button, a live session log and a box to compose messages. The connection is raw RFC 6455 and stays open as long as the tab does. The log is ephemeral — it lives in memory and disappears with the tab, while the request history records only the fact that a connection was opened.

Connecting#

The protocol is chosen when the request is created: the New Request dialog offers WebSocket next to HTTP, gRPC and GraphQL. The address field then expects a URL with a ws:// or wss:// scheme; anything else is rejected with a validation error before a socket is attempted, so a plain HTTP address cannot slip through.

Connect (or Enter in the address field) opens the connection, and the same button turns into Disconnect. While the connection is live the address is read-only — disconnect first if you need to change it.

Environment variables are resolved in the address, and the environment picker sits in the tab header, so {{ws_host}}/socket moves between environments without touching the request. See environments and variables.

Auth is applied to the handshake — the HTTP request that upgrades into the socket. A request stored in a collection that has auth configured, with its own type left as inherit, gets that header automatically; inheritance is described in authentication. The handshake itself has 30 seconds to complete.

Sending messages#

The composer at the bottom of the tab is an editor with JSON highlighting. Send it with the Send button or Cmd/Ctrl+Enter — in a WebSocket tab that shortcut sends the message instead of executing the request, as it does for the other protocols. The box is cleared after sending, and Send is only enabled while the connection is live.

Outgoing frames are text. The line appears in the log immediately; if the write to the socket fails, the row is dimmed and marked with a warning sign so a lost message is not mistaken for a delivered one.

The session log#

Every row carries a direction, a timestamp and the payload. Incoming frames are green, outgoing are violet, and system rows about errors and disconnects use their own color. Long payloads are truncated to the width of the pane; clicking a row expands the full body and clicking again collapses it. The log follows the newest message.

Tetiva
v0.17.0
A WebSocket tab in Tetiva: the address, the Disconnect button and a live session logA WebSocket tab in Tetiva: the address, the Disconnect button and a live session log
Incoming frames are green, outgoing violet; the log lives as long as the tab does

Binary frames arrive Base64-encoded — raw bytes do not survive the app's event boundary intact. A single incoming message is limited to 8 MiB.

What is kept and what is not#

The log only exists while the tab is open. Closing the tab drops the connection and discards the messages; reopening the request gives you an empty log with "No messages yet". The request itself — name, address, collection — is saved as usual with Cmd/Ctrl+S.

The request history gets one record per connection: the protocol, the resolved address and the outcome — status 101 for a successful handshake, or the error text if the socket never opened. Session messages are not written to history, so copy anything you need out of the log before closing the tab. History and replay are covered in response viewer.

updated