fix: Correctly handle shared memory for DataView initialization in deserialize_binary...
authorottomated <31470743+ottomated@users.noreply.github.com>
Fri, 5 Dec 2025 00:11:20 +0000 (16:11 -0800)
committerGitHub <noreply@github.com>
Fri, 5 Dec 2025 00:11:20 +0000 (17:11 -0700)
commit1f2b4c36fd1aeadd4971a4d0029cd75d256bda51
treecb77d145b3fea81c7e13b724faae1bb3af1d9cea
parentcd6837c47f271caecae9b7c105b8c2e96da83aa4
fix: Correctly handle shared memory for DataView initialization in deserialize_binary_form (#15028)

* Fix DataView initialization in form-utils.js:deserialize_binary_form

When you call get_buffer, it returns a Uint8Array. In many JavaScript runtime environments (like Cloudflare Workers, Node.js, or modern browsers), streams often allocate chunks from a shared memory pool (slab allocation). This means the Uint8Array you get back is a view into a much larger ArrayBuffer, and it often has a non-zero byteOffset.

When you pass header.buffer to DataView, it creates a view starting at the very beginning (byte 0) of the underlying memory allocation, completely ignoring the byteOffset of your header array.

Because the header data usually lives at a specific offset inside that buffer, your code reads 4 bytes from the wrong location (the start of the memory slab), interprets that garbage data as a 32-bit integer, and gets 16793089 (in my test case). It then tries to read ~16MB of data, runs out of stream, and throws "data too short".

You must pass the byteOffset and byteLength to the DataView constructor to ensure it looks at the correct slice of memory.

I have confirmed on my code that this fix resolves my problem.

* Remove unnecessary comment

* add test & changeset

---------

Co-authored-by: Marat Vyshegorodtsev <github@v.marat.to>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
.changeset/thick-spiders-invite.md [new file with mode: 0644]
packages/kit/src/runtime/form-utils.js
packages/kit/src/runtime/form-utils.spec.js