DevTools/Websocket/Roadmap
Overview
Developers should be able to debug and monitor websocket-based communications using Mozilla Firefox developer tools.
At a high level, the tool should allow for the inspection of websocket frames and for notifications for any of the major websocket state change events, such as open, close, errors, handshakes and protocol upgrade events.
It should also be possible for the community to extend the websocket monitoring framework to support specific protocol parsing so that protocols can also be monitored.
The platform work for websocket did not include any support for being able to debug and monitor websocket communications. As a result, any tooling will have to be preceded by some platform work to enable tooling.
Features at a Glance
Websocket frames
The heart of the tooling should enable developers to inspect individual websocket frames. Pretty much everything can be added on top of individual frame inspection.
Websocket state changes
http handshakes, Open, close, error and protocol upgrades are the major websocket events that should be visible in a tool.
Multiple websocket connections
Whatever tool we implement, it has to have support for multiple websocket connections. This could be achieved by providing a filter, or by having the UI display any websocket data based on each WS connection.
Protocol support
WS was designed specifically so that developers did not have to be constrained by the http protocol and instead can select the most appropriate protocol for the task they are trying to solve. For example. STOMP or AMQP are popular protocols for solving publish/subscribe type problems such as those encountered in stock market applications. SocketIO is a protocol that was loosely implemented for chat problems but is used extensively for many applications requiring basic real time messaging.
The most ubiquitous tasks for developers is to be able to inspect payloads for specific protocols. Such inspection includes both the payload itself (JSON, Binary JSON, binary) and the wrapper, such as message options and topic and subscription information, i.e. who is supposed to receive the message. The knowledge of the protocol is embedded in the protocol upgrade event, and if it's a readable protocol, our tool should be smart enough to use the right parser. Any given payload is an assembly of frames that have to be pieced together by the parser according to the protocol.
The three most popular open source protocols are SocketIO, STOMP, and AMQP, but AMQP does come in two distinct flavors, v. 0.9 and v. 1.0, both are in use and are very different. We should solicit the community to help us implement the parsers.
websocket extensions
The WS standard supports WS extensions. These allow specific vendors to add meta-data to frames so that additional functionality can be overlaid on a websocket stream independent of which protocol runs on the websocket connection. Our tools should be smart enough to decipher the content of the meta-frame data.
User stories
- bla bal bal, awhatever.
Existing Bugzilla tickets
- [https://bugzilla.mozilla.org/show_bug.cgi?id=xxxxx bla bla bla.
Other Requirement Docs
OPEN QUESTIONS
Design Discussions
Platform APIs
Mockups
Latest Sketches
Competitive Analysis
| Tool | Frame Inspection | Protocol Specific Inspection | Event/State Inspection | Extensibility | Connection Filtering | Search | WS Extension support |
|---|---|---|---|---|---|---|---|
| Fiddler | ✓ | ✓ | ✓ | ||||
| Chrome Tools | ✓ | ✓ | ✓ | ? | |||
| IE11 DevTools |
