Resizable ArrayBuffers and Response and Request objects

[jasnell]

@domenic @annevk ... Wondering what the expected behavior should be here with the upcoming introduction of resizable ArrayBuffers.

Assuming something like the following:

const enc = new TextEncoder();
const ab = new ArrayBuffer(10, { maxByteLength: 20 })
const u8 = new Uint8Array(ab, 0, 10);
const resp = new Response(u8);

// Edit u8 after calling new Response...
enc.encodeInto('hellothere', u8);

// Resize after calling new Response...
ab.resize(8);

What should be expect the Content-Length and payload content of resp to be?

• Option 1: Content-Length == 10, payload \0000\0000\0000\0000\0000\0000\0000\0000\0000\0000
• Option 2: Content-Length == 10, payload hellothe\0000\0000
• Option 3: Content-Length == 8, payload hellothe
• Option 4: Something else?

Should the u8/ab become detached when passed to new Response(...)? If not, why not? Could we potentially look at detaching as an option?

Does the spec need to be updated to account for resizable ArrayBuffer?

I should acknowledge that yes, I'm very aware there is already potential for weirdness here allowing TypedArrays/ArrayBuffers used with Response and Request to be modified after they have been passed in but before they are consumed, resizable ArrayBuffers just makes it potentially a bit weirder. I'll note that browsers, Deno, and Node.js all appear to copy the value passed in immediately and do not pick up changes made to the ArrayBuffer after the fact (that is, they currently appear to implement option 1) but in Workers we'd currently end up with Option 2, so I want to verify what is the expected correct behavior?

[domenic]

The constructor eventually gets the contents of the ArrayBuffer via https://fetch.spec.whatwg.org/#concept-bodyinit-extract, which calls https://webidl.spec.whatwg.org/#dfn-get-buffer-source-copy . So any changes after calling new Response() are ignored. I.e., option 1 is correct per specs.

Hope this helps!

[jasnell]

Yep that helps!

[annevk]

Huh wait. Wouldn't it throw due to it not having [AllowResizable]?

@syg please add a test for this.

Reopening for now until we have clarity.

[domenic]

Ah yeah, I think I skipped over the resizable part and over-focused on the mutation-after-passing part. My bad!

[syg]

@syg please add a test for this.

Done as part of https://chromium-review.googlesource.com/c/chromium/src/+/4082152

[annevk]

In case someone stumbles across this in the future, the corresponding HTML PR is whatwg/html#8559.