HttpResponse.json() returns Content-Type text/plain

[Lmh-java]

Hey team,

A producible example is found. It seems this following problem comes from a polyfill conflict with installGlobals() from Remix. A producible demo can be seen here. I wonder if this is the right place to report this issue. If not, please suggest. :)

First of all, I am sorry that I can't provide a reproducable demo for you. We tried to reproduce in a blank project, but msw seems be working well in those cases. It only behaves weirdly in our private project, but I can't share it here. Therefore, I am opening an issue here to see if I can get some insights.

Issue:

HttpResponse.json() returns Content-Type text/plain

When does this issue happen:

We are trying to update msw from 2.4.2 to 2.7.0, (I believe any version >= 2.4.4 does not work in our project). Here are the changes.

When we are using HttpResponse.json({}) to mock a reponse for an api, this returns a response with Content-Type of plain/text. In our project, these responses are treated as strings, so when we are accessing properties from these stringified objects, it causes problems.

HttpResponse.json() should return content type of application/json.

Investigation

After further investigations, we found out, that the issue happens in normalizeResponseInit(). The Headers copy constructor takes in a headers with proper content type and return an empty object {}. This causes the built-in Response class to attempt to recognize the content-type based on the response body. In our case, it will be a string, which gives text/plain.

This copy constructor issue is also directly reproducible in our the project, if we do something like

const h = new Headers();
h.set("Content-Type", "application/json");
const ah = new Headers(h);
console.log(ah); // this prints out  "{}"

Further investigation

If we do

// without any import statements to Headers
console.log(Headers)

this gives us [Headers extends URLSearchParam]. This might be an indicator that the Headers class is provided by some polyfills from node-fetch, because in the implementation of Headers in node-fetch, it extends URLSearchParam. See here.

Digging more into the code, I think the only update that stood out to me is the update in msw/interceptor dependency if we take a look at the compare. After some binary search, we found out the issue begins with @mswjs/[email protected]. Even if we manually override the @mswjs/interceptors version to 0.32.0, there is no problem.

This is what has been changed (here). One thing that seems to be causing the problem is in src/interceptors/ClientRequest/utils/recordRawHeaders.ts, where the globalThis.Headers is overridden.

Thank you!