docs(uts): proxy supports both JSON and msgpack, not text frames only#496
Open
sacOO7 wants to merge 1 commit into
Open
docs(uts): proxy supports both JSON and msgpack, not text frames only#496sacOO7 wants to merge 1 commit into
sacOO7 wants to merge 1 commit into
Conversation
b8c3684 to
7aa0bc8
Compare
uts-proxy v0.3.0 (ably/uts-proxy#4) derives a WebSocket message's encoding from the `format` query parameter — matching the Ably server — rather than from the WebSocket frame type. The proxy can therefore decode and match both JSON and msgpack messages, including SDKs (e.g. ably-java) that send JSON payloads over binary WebSocket frames.
7aa0bc8 to
06ac7d4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Corrects the integration-testing policy doc, which incorrectly stated that the test proxy is limited to JSON / text WebSocket frames.
uts-proxyv0.3.0 changed the proxy to determine a WebSocket message's encoding from theformatquery parameter (mirroring the real Ably server) instead of from the WebSocket frame type (text vs binary). The proxy can now decode, match, and act on both JSON and msgpack messages.What was wrong
uts/docs/integration-testing.mdclaimed:This assumption (frame opcode ⇒ encoding) was never how the Ably server behaves, and it broke proxy frame-inspection in a non-obvious way: SDKs that send JSON payloads over binary WebSocket frames (e.g. ably-java, even with
useBinaryProtocol: false) had their client→server frames logged by the proxy as unparseable ({"_binary": true, "action": -1}). Any proxy rule or assertion matching on a client-sent protocol-messageactiontherefore silently failed, even though the SDK was behaving correctly and the real server accepted the frames.What changed
Updated the Protocol Variants section to reflect v0.3.0:
formatquery parameter, matching the server.## Protocol Variantsconvention; JSON is pinned only when the SDK under test does not implement msgpack (an SDK constraint, not a proxy one).References
🤖 Generated with Claude Code