[tonytonycoder11]

A WebSocket used to end its call as soon as the upgrade went through, and an event stream was one long response body. Both are now conversations: the call stays open, lists its messages as they cross, and gets a Messages or Events tab.

WebSockets. The capture wraps the socket that dart:io detaches after the handshake and reads the frames of both directions from the bytes that cross it. Fragmented messages are joined, permessage-deflate messages are decompressed (with or without a window kept between messages, as the handshake agreed), and ping, pong and close frames are listed as messages of their own. A reader that meets bytes it cannot make sense of stops and says nothing more, and it never changes what the app reads or writes. The call ends when both sides have sent a close frame, when the other side stops sending, when the socket is destroyed or when it fails. It is not cancelled when the app closes the client that opened it, which apps do once the handshake is over.

Event streams. A text/event-stream response is parsed as it arrives, by the rules of the HTML standard, and each complete event becomes a message. The raw stream is still the body of the response.

What a call keeps. The latest thousand messages and a megabyte of payload, each message cut at maxBodyBytes, with the real size and the count of everything that came before. Text goes through the redaction like a body does. The address of a WebSocket is recorded as the app wrote it, wss://host/path, and not as the HTTP request the handshake is.

Where it shows:

• A Messages or Events tab with a direction filter. It follows the newest message while the call runs, and a message opens in the body viewer, so a JSON message is a tree.
• A badge in the list and a line in the overview.
• The HAR export, with _webSocketMessages the way Chrome writes it and _eventSourceMessages for streams, and the text export.
• The messages are kept on disk with the call and counted in the memory and disk budgets.

A WebSocket is not offered for sending again, because its handshake is not a request that stands alone.

One limit, written in the package README: dart:io makes one client for every WebSocket the first time one is opened, so a WebSocket opened before Flutwire.init is not seen. On the web nothing is recorded, because the browser opens WebSockets itself.

I tried it on an Android emulator with the example app, which has a new Streams section: a WebSocket against an echo server, with text, JSON and binary messages and the close frame, and an event stream from a public feed. All four suites pass, flutter analyze --fatal-infos is clean and the example builds for the web.

Targets 0.2.0, Tier 2, M16.

[trueup-by-nacode-studios]

This pull request adds no capability the code did not already have.

_{38 files read · 2653 ms · against 36d8943 · engine 1.4.1}