Environment
ofetch v1.0.0
node v16.19.0
Reproduction
https://gist.github.com/marr/4243d2bd64f9c0abe8b1f135ae7c7eb6
I've created a simple repro using a mock postman server. You won't be able to see the logs with the URL that my repro case is creating. You can get basic "request logs" by creating a mock server in postman and sending a PATCH or POST request to it.
The Request Body in the mock server log is correctly a JSON object, only when the body is stringified in the request. I've not been able to reproduce in the ofetch tests yet.
Describe the bug
The incorrect behavior can be seen in the screenshot below.

Note the request was sent like: await ofetch(url, { body: { x: 1 }, method: "PATCH" });
The desired request body looks like this:

You can see the content-type and accept headers are set and the request body looks correct. This used a stringified version of the body in the request:
await ofetch(url, { body: JSON.stringify({ x: 1 }), method: "PATCH" });
Additional context
No response
Logs
No response
Environment
ofetch v1.0.0
node v16.19.0
Reproduction
https://gist.github.com/marr/4243d2bd64f9c0abe8b1f135ae7c7eb6
I've created a simple repro using a mock postman server. You won't be able to see the logs with the URL that my repro case is creating. You can get basic "request logs" by creating a mock server in postman and sending a PATCH or POST request to it.
The Request Body in the mock server log is correctly a JSON object, only when the
bodyis stringified in the request. I've not been able to reproduce in the ofetch tests yet.Describe the bug
The incorrect behavior can be seen in the screenshot below.

Note the request was sent like:
await ofetch(url, { body: { x: 1 }, method: "PATCH" });The desired request body looks like this:

You can see the
content-typeandacceptheaders are set and the request body looks correct. This used a stringified version of the body in the request:await ofetch(url, { body: JSON.stringify({ x: 1 }), method: "PATCH" });Additional context
No response
Logs
No response