fix(openapi-fetch): fix headers for FormData

[psychedelicious]

We need to delete the Content-Type header if the serialized body is a FormData. This allows the browser to set the Content-Type and boundary expression correctly.

Resolves #1191

Changes

If you set Content-Type to multipart/form-data explicitly, the browser does not set boundary.

Because FormData gets special handling by the browser, we need to give it special handling too.

Check if the serialized body is an instance of FormData, and if so, delete the Content-Type header.

Resolves #1191

How to Review

I've tested this in my production app but I think you'd need to whip up a simple test project to see for yourself. I'm out of time for that today though, sorry!

One hiccup in the tests - vitest-fetch-mock does not add the form field boundary like the browser does. Ideally we could confirm that the Content-Type for FormData bodies are correct:

// expect requests with FormData to have correct Content-Type with boundary expression
expect((req.headers as Headers).get("Content-Type")).toMatch(/^multipart\/form-data; boundary=.*/);

Instead, we must check if it is null:

// `vitest-fetch-mock` does not add the boundary to the Content-Type header like browsers do, so we expect the header to be null
expect((req.headers as Headers).get("Content-Type")).toBeNull();

edit: Oh, maybe it's just that the browser adds the boundary as the request is processed, and testing for null is correct

@nilsso Please give try this out.

Checklist

• Unit tests updated
• README updated
• [ ] examples/ directory updated (only applicable for openapi-typescript)

[changeset-bot]

🦋 Changeset detected

Latest commit: ff5c633

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openapi-fetch	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[drwpow]

Thanks for opening this PR! I’m in favor of merging this PR. Just had a minor nitpick on one unneeded change before approving and merging though. Otherwise looks great