WebSocket-запрос в Tetiva устроен как остальные: адрес, вкладки и панель — только вместо одной отправки здесь живое соединение. Вкладок шесть: Messages, Params, Auth, Headers, Scripts, Docs. Адрес, селектор окружения, Settings и Connect стоят в строке над вкладками и доступны на любой из них; запрос открывается на Messages, где лежат строка статуса, лог сессии и поле для отправки. Соединение идёт по сырому протоколу RFC 6455 и держится, пока открыта вкладка. Лог эфемерный — он живёт в памяти приложения и исчезает вместе с вкладкой, а в историю запросов уходит рукопожатие.
Подключение#
Протокол выбирается при создании запроса — в диалоге «Новый запрос» рядом с HTTP, gRPC и GraphQL есть кнопка WebSocket. Дальше в адресной строке вкладки нужен URL со схемой ws:// или wss://; другие схемы отклоняются с ошибкой валидации ещё до вызова, чтобы не пытаться открыть сокет к обычному HTTP-адресу.
Подключение запускает кнопка Connect или Enter в адресной строке; та же кнопка превращается в Disconnect. Пока соединение живо, адрес заблокирован от правок — чтобы поменять его, сначала отключитесь. На рукопожатие отводится 30 секунд. Автоматического переподключения нет: разорванное соединение остаётся разорванным, пока вы не нажмёте Connect.
В адресе подставляются переменные активного окружения, а селектор окружения стоит прямо в шапке вкладки: {{ws_host}}/socket переключается между стендами без правки запроса. См. окружения и переменные.
Настройки сокета#
Кнопка Settings между селектором окружения и Connect открывает поповер с двумя полями:
Ping every … seconds (0 = off)— клиент сам шлёт ping с этим интервалом и ждёт ответа 10 секунд. Не дождался — в лог падает системная строкаkeepalive ping timed out, и соединение считается разорванным.Subprotocols (comma-separated)— список подпротоколов для рукопожатия, напримерgraphql-ws, json.
Кнопка Apply записывает значения в запрос. При живом соединении внизу поповера стоит Applies on the next connection. — переподключитесь, чтобы новые значения вступили в силу. Подпротокол, о котором договорились с сервером, виден чипом в строке статуса.
Авторизация и куки#
Авторизация применяется на handshake — то есть на том самом HTTP-запросе, которым открывается соединение. Во вкладке Auth у WebSocket-запроса доступны Inherit, None, Basic Auth, Bearer Token, API Key, OAuth 2.0 и JWT Bearer. Digest и AWS Signature работают только по HTTP: если такая схема осталась на запросе, под селектором висит янтарная строка с её именем — Digest is supported for HTTP requests only; this request will fail to send. Наследование от коллекции работает как обычно — см. авторизацию.
Куки воркспейса для этого адреса прикладываются к рукопожатию, а Set-Cookie из ответа 101 сохраняется обратно в то же хранилище. Хранилище общее с HTTP-запросами: сначала логин обычным POST, потом сокет с уже готовой сессионной кукой.
Скрипт перед подключением#
Во вкладке Scripts у WebSocket-запроса одна кнопка — «Перед подключением». Фазы post-response здесь нет: нет единственного ответа, к которому её привязать. Скрипт выполняется перед рукопожатием, и всё, что он записал через pm.environment.set, подставляется и в адрес, и в заголовки рукопожатия и сохраняется в активное окружение сразу после скрипта — до рукопожатия, поэтому остаётся там, даже если подключиться не удалось. Если же скрипт упал с ошибкой, подключения не будет вовсе: в журнале появится The pre-connect script of this request failed: с текстом ошибки, строкой и тем, что скрипт успел напечатать, а в окружение ничего не сохранится.
Сходить за токеном прямо из скрипта нельзя: в песочнице нет ни сети, ни таймеров, а на выполнение отводится 5 секунд. Скрипт умеет вычислить значение или переложить уже имеющееся — подпись, идентификатор, метку времени. Полный список pm.* — на странице Скрипты.
Отправка сообщений#
Внизу вкладки Messages — переключатель формата и поле ввода. Форматов три:
JSON— редактор с подсветкой;Text— тот же редактор без неё;Binary— однострочное поле с плейсхолдеромbase64 payload. Строка должна быть корректным base64 с выравниванием, иначе отправка остановится с ошибкойBinary messages must be base64.
Отправить содержимое можно кнопкой Send или Cmd/Ctrl+Enter: в WebSocket-вкладке этот шорткат отправляет сообщение, а не выполняет запрос, как в остальных протоколах. После отправки поле очищается, кнопка Send доступна только при живом соединении.
В текстовых сообщениях подставляются переменные окружения, и подставляются заново на каждую отправку — обновлённый в другом месте токен подхватывается без переподключения. Бинарные кадры уходят как есть.
Отправленная строка появляется в логе сразу; если запись в сокет не удалась, строка помечается предупреждающим значком и приглушается — так видно, что сообщение не ушло.
Сохранённые сообщения. Кнопка Save рядом с Send активна, пока в поле есть что-то кроме пробелов: она спрашивает имя (Message name, Enter — сохранить, Esc — отменить) и кладёт сообщение чипом над полем ввода. Клик по чипу подставляет сообщение обратно в поле, двойной клик переименовывает, крестик удаляет без подтверждения. Заготовки лежат внутри самого запроса, поэтому переживают перезапуск приложения и уезжают вместе с ним.
Лог сессии#
Каждая строка лога — направление, время и содержимое. Входящие подсвечены зелёным, исходящие — фиолетовым, служебные сообщения о разрыве и ошибках идут отдельным цветом. Длинная строка обрезается по ширине; клик по ней разворачивает полное тело и сворачивает обратно. Лог сам прокручивается к последнему сообщению. Кнопок очистки и фильтра у него нет.
Входящие бинарные кадры приходят в кодировке Base64 и помечены в логе чипом BIN — сырые байты не переживают границу событий приложения. Ограничение на одно входящее сообщение — 8 МиБ.
Что сохраняется, а что нет#
Лог живёт только пока открыта вкладка. Закрытие вкладки разрывает соединение и стирает историю сообщений — переоткрыв запрос, вы получите пустой лог с надписью No messages yet. Сохранённые сообщения и настройки сокета записываются сразу — по кнопке Apply и по подтверждению имени сообщения; остальное — имя, адрес, Params, Auth, Headers, Scripts и Docs — сохраняется по Cmd/Ctrl+S.
В историю запросов пишется одна запись на подключение: адрес, заголовки запроса в том виде, в каком их собрало приложение, код ответа (101 при успехе или тот статус, который вернуло отказавшее рукопожатие, — обычно 401 или 403), заголовки ответа и время подключения. Ответная часть настоящая, а запросная собрана до дозвона: cookie из jar и заголовки Sec-WebSocket-*, которые добавляет библиотека, в неё не попадают. Сообщения сессии в историю не попадают, так что переписку нужно скопировать из лога до закрытия вкладки. В фильтре истории у WebSocket свой чип — WS рядом с HTTP, gRPC и GraphQL. Как устроена история и повтор запросов — в разделе просмотр ответа.