feat: implement Response.clone()

[godronus]

Implement Response.clone() (WHATWG Fetch)

Implements Response.clone() per the WHATWG Fetch spec. All 21 WPT tests in
fetch/api/response/response-clone.any.js pass.

Approach

Response bodies are modelled as default (non-byte) ReadableStreams, whose tee shares a single
chunk object between both branches. Fetch's "clone a body" requires the clone to receive independent
copies, so Response::clone implements the WHATWG ReadableStreamDefaultTee algorithm with
cloneForBranch2 = true:

• A single reader drains the source body stream.
• Each chunk is enqueued unchanged into branch1 (the original response's body), preserving
  object identity, and a JSAutoStructuredCloneBuffer copy is enqueued into branch2 (the clone's
  body).
• The copy is made eagerly, in the source read, before either consumer observes the chunk — a
  lazy copy would be read-order dependent and would duplicate already-mutated bytes if the original
  branch is read and mutated in place first.

Cancellation is tracked per branch (canceled1/canceled2): a cancelled branch is dropped from the
read loop while the other continues.

sc_callbacks is not needed — body chunks are TypedArray/ArrayBuffer/DataView, handled by the
built-in structured clone.

Design notes

• Cost: one structured-clone copy per chunk, clone branch only; branch1 is zero-copy. Same copy
  count as the spec byte-stream tee. highWaterMark is 0 and chunks are pulled on demand, so the
  body is never fully buffered.
• Byte streams: modelling bodies as byte streams would let the native byte-stream tee provide
  this directly (CloneAsUint8Array, no hand-rolled tee), but that is a large change across all
  body I/O and is out of scope here.
• Request::clone currently tees without copying branch2; aligning it is a reasonable
  follow-up.

Changes

builtins/web/fetch/request-response.h

• Added Response::clone declaration.

builtins/web/fetch/request-response.cpp

• Added #include "js/StructuredClone.h".
• Request::bodyUsed_get / Response::bodyUsed_get: fall back to JS::ReadableStreamIsDisturbed
  when the BodyUsed slot is false, so bodyUsed reports true after body.cancel() and other
  external stream disturbances.
• Added the tee implementation: CloneTeeSlot (shared-state layout), clone_tee_pump,
  clone_tee_read_then_handler, clone_tee_read_catch_handler, clone_tee_cancel_algorithm,
  clone_tee_pull_algorithm.
• Implemented Response::clone: acquires a default reader on the body, creates two
  NativeStreamSource branches over shared tee state, and assigns branch1 to the original response
  and branch2 to the clone.
• Registered JS_FN("clone", Response::clone, 0, JSPROP_ENUMERATE).

tests/wpt-harness/expectations/fetch/api/response/response-clone.any.js.json

• New file — 21/21 passing.

WPT results

fetch/api/response/response-clone.any.js — 21/21 pass.

Side-effect fixes from the ReadableStreamIsDisturbed fallback in bodyUsed_get:

• fetch/api/response/response-stream-disturbed-6.any.js — 5 FAIL → PASS (partially resolves Stream disturbed test failures #184)
• fetch/api/response/response-stream-disturbed-by-pipe.any.js — 2 FAIL → PASS
• fetch/api/request/request-disturbed.any.js — 1 FAIL → PASS
• fetch/api/abort/general.any.js — 2 FAIL → PASS

fetch/api/body/mime-type.any.js — new expectations file (6 PASS, 14 FAIL). The file previously
aborted during initialisation on a top-level clone() that threw TypeError; it now loads, and the
14 failures expose a pre-existing gap where parse_body<Blob> does not populate blob.type from
the Content-Type header. Tracked in #311.

Downstream testing: PASSING

https://github.com/G-Core/FastEdge-sdk-js/blob/main/integration-tests/test-application/handlers/response-clone.ts

[andreiltd]

Thank you! Looks good. It's a bit unfortunate that we cannot use SpiderMonkey's ReadableStreamTee here directly.

That said, I think those changes will break RequestOrResponse::maybe_stream_body assumptions: https://github.com/bytecodealliance/StarlingMonkey/blob/main/builtins/web/fetch/request-response.cpp#L1223

IIUC Response::clone() can install tee branches into BodyStream, but leaves the original incoming response handle in place and maydbe_body_stream will bypass the tee branch?

See the comment:

 // Those can be handled by direct use of async tasks and the host API, without needing
 // to use JS streams at all.  

Also, this has to be rebased to include: #313, because it will change wpt expectations. Is that correct?

[andreiltd]

@tschneidereit did you want to have another look? If I'm not mistaken you're fresh out of the stream implementation 🙂

[godronus]

That said, I think those changes will break RequestOrResponse::maybe_stream_body

Good catch — fixed in the latest push.

One-liner in maybe_stream_body: also gate the incoming fast-path on !body_stream(body_owner), so once a BodyStream exists (.body access or a clone() tee) we fall through to the JS-stream path and honor the tee branch instead of draining the raw handle. Sits in the shared path, so Request::clone gets the same fix for free.

Impact: basically nil for normal apps — proxy / header-rewrite / fetch-and-return never reify BodyStream, so they keep the zero-copy host append. It only diverts for cloned incoming responses, which then stream through JS in 8 KB chunks rather than a single host append — cost proportional to body size, and those callers were already paying that on the branch they read. Correctness over a micro-opt on the one path that needs it.

I did look at gating on an explicit "was teed" flag to keep the fast-path for the bare .body-reify case, but that only helps "reify .body, never read it, return the same object" — which doesn't really happen — so I went with the simpler guard.

All WPT + unit tests still green.

Also, this has to be rebased to include: #313, because it will change wpt expectations. Is that correct?

yes, WPT expectations will have some "FAIL" with this branch alone and rebasing #313 will make them all "PASS"
REBASED

[andreiltd]

Thanks!