[Evan Rusackas (rusackas)]

Summary

response.body() for a page-level Response can return an empty buffer once the page's own JS has already consumed the same fetch() response (e.g. via .blob()), on any request whose CDP resource type isn't in kRefetchSafeResourceTypes (i.e. anything but static subresources / prefetches) - most notably plain fetch()/XHR GETs. Filed as #42862, with a minimal, version-bisected repro (works on 1.62.1, broken on 1.63.0).

Root cause

#42124 / #42201 restricted the evicted-body recovery path (Network.loadNetworkResource re-fetch) to static-subresource GETs and prefetch requests, to stop harTracer's automatic per-response HAR/trace capture from silently re-issuing requests with server-side side effects (#42002 - a tracking pixel getting hit twice).

That fix is correct for the case it targets, but the same restriction also gates the case where a test explicitly awaits response.body() once, for one response it already asked for by name (page.waitForResponse(...) then await response.body()). That's a fundamentally different risk: harTracer calls internalBody() on every response with no way to opt out, while an explicit response.body() call is a one-off the caller deliberately wrote. Gating both the same way means any app that reads a fetch()/XHR response in-page (e.g. const blob = await response.blob() before turning it into a download - a completely ordinary pattern) makes that response's body permanently unrecoverable for any later response.body() call, once Chromium evicts it.

Fix

Thread an isExplicit flag from Response.body() (the client-facing, dispatcher-driven entrypoint) down through internalBody() to createResponseBodyCallback(), defaulting to false:

• harTracer.ts's existing response.internalBody() call is untouched, so the automatic HAR/trace capture path keeps exactly today's restrictive behavior and [Bug]: Tracing silently re-downloads resources via Network.loadNetworkResource, duplicating requests with side effects (Chromium only) #42002 stays fixed.
• Response.body() now calls internalBody(true), so an explicit caller can recover an evicted body for any GET, not just the static-subresource/prefetch allowlist.
• The method !== 'GET' check is unconditional either way: an explicit body() call is not an invitation to resubmit a POST.

GetResponseBodyCallback gained a parameter; Firefox/WebKit/BiDi's existing zero-argument callbacks are unchanged and still satisfy the (now one-parameter) type, since a function with fewer declared parameters is assignable to a type expecting more. Only Chromium's implementation needed a behavior change.

Testing

• Added should return body for a fetch()ed resource with evicted body when the page already read it next to the existing should return body for image with evicted body (fix(chromium): only re-fetch replay-safe requests when reading response body #42124's own regression test) in tests/page/page-network-response.spec.ts.
• Verified the new test fails without this fix (confirmed by reverting the fix, rebuilding, and re-running: Expected: "hello from resource.bin", Received: "") and passes with it.
• Full tests/page/page-network-response.spec.ts: 29 passed.
• tests/library/har.spec.ts + tests/library/browsercontext-har.spec.ts: 97 passed, 1 skipped (unrelated) - confirms the harTracer path (and [Bug]: Tracing silently re-downloads resources via Network.loadNetworkResource, duplicating requests with side effects (Chromium only) #42002's fix) is unaffected.
• tests/library/tracing.spec.ts: 40 passed, 1 skipped (unrelated).
• npm run lint (eslint, tsc, doc, check-deps, lint-tests, test-types, lint-packages): clean, only one pre-existing unrelated warning in trace-viewer/workbench.tsx.

Fixes #42862

[Evan Rusackas (rusackas)]

Thanks in advance for any CI approval and review comments... happy to help here wherever I'm able.