New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloned responses do not clone the underlying stream #1216
Labels
bug
Something isn't working
Comments
cprecioso
pushed a commit
to cprecioso/happy-dom
that referenced
this issue
Jan 17, 2024
cprecioso
pushed a commit
to cprecioso/happy-dom
that referenced
this issue
Jan 17, 2024
capricorn86
added a commit
to cprecioso/happy-dom
that referenced
this issue
Mar 9, 2024
…eam when cloning a Response body
capricorn86
added a commit
to cprecioso/happy-dom
that referenced
this issue
Mar 9, 2024
capricorn86
added a commit
to cprecioso/happy-dom
that referenced
this issue
Mar 9, 2024
capricorn86
added a commit
that referenced
this issue
Mar 9, 2024
#1216@patch: Clone response body when cloning a response.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Doing a
fetch
, and then cloning theResponse
will give you 2 response objects.In the browser, you can use these separately, and when you consume the Response, the other one is not consumed (as described on MDN).
In happy-dom, consuming either of them will consume both, rendering the
.clone()
operation useless.To Reproduce
Response.json({foo:"bar"})
do not have this bugfetch()
, both requests will work correctly (I suspect this is due to correctly implemented cloning for the internal cache).Expected behavior
Both response objects return the correct response text even if the other one has been consumed.
You can copy the code (minus the
new Window()
) to your browser console and see it working correctly.Screenshots
-
Device:
node v20.11.0 on macOS Sonoma 14.2.1
Additional context
-
The text was updated successfully, but these errors were encountered: