fix(wasm-visor): read Uint8Array/ArrayBuffer request bodies (POSTs were corrupted to "<object>") - #3935
Open
0pcom wants to merge 2 commits into
Open
fix(wasm-visor): read Uint8Array/ArrayBuffer request bodies (POSTs were corrupted to "<object>")#39350pcom wants to merge 2 commits into
0pcom wants to merge 2 commits into
Conversation
…ject>" jsFetchDmsg and jsFetchClearnet read the optional request body with `[]byte(args[3].String())`. The real-origin browse responder (browse-responder.js) passes the body as a Uint8Array, and syscall/js Value.String() on a non-string value returns the literal string "<object>" — so every browser POST/PUT issued through the in-tab wasm-visor browser had its body silently replaced with the 8 bytes "<object>" before it left the visor. Confirmed live: a mesh browse POST of "x=42&y=sky" arrived at the server as "<object>" (GET, XHR and 302-redirect all worked; only the body was corrupted). Add jsBodyBytes(): string bodies pass through as before; Uint8Array, other typed arrays / DataView, and ArrayBuffer are copied out with js.CopyBytesToGo. Used by both fetch bindings, so form-encoded and binary POSTs (browser uploads, skycoin-API form posts) carry their real bytes.
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
1 participant
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.
Bug
Every POST/PUT issued from the in-tab wasm-visor browser had its body silently replaced with the 8 bytes
"<object>".jsFetchDmsg(cmd/wasm-visor/main.go) andjsFetchClearnet(skysocks_js.go) read the body with[]byte(args[3].String());browse-responder.jspasses it as aUint8Array, and syscall/jsValue.String()on a non-string returns the literal"<object>".Verified live (byte-for-byte)
Mesh HTTP echo served over
.dmsg, SW-controlled iframe on the:8443harness vs a native SOCKS client (curlon:4445→:4446→:1080):x=42&y=sky: before → echo"<object>"(8 bytes); after →x=42&y=sky(10) ✓[1,2,3,255,0,66]: 6 bytes preserved ✓{"method":"POST","echo":"PARITY_test_&z=9","len":16}This completes the wasm-iframe browser's request-type matrix (navigation, subresources, XHR, redirects, POSTs) at byte-for-byte parity with the SOCKS5 resolving-proxy chain.
Fix
jsBodyBytes(js.Value): strings pass through;Uint8Array/ typed arrays /DataView/ArrayBuffercopied out viajs.CopyBytesToGo. Used by both fetch bindings. Includes the regenerated std-Go embed blob built clean on top of the code fix.