Multipart boundary mismatch when using search params

[alanshaw]

Multipart boundary in content-type does not match boundary in body when using ky with searchParams. This bug was introduced in #208

The following example is effectively what happens here

ky/index.js

Line 242 in d6ff489

this.request = new globals.Request(new globals.Request(url, this.request), this._options);

const fd = new FormData
fd.append('test', new Blob(['data'], { type: 'application/octet-stream' }))

const opts =  { method: 'post', body: fd }
const r0 = new Request('/test', opts)
const r1 = new Request('/test?foo=bar', r0)
const r2 = new Request(r1, opts)

console.log(r2.headers.get('content-type'))
// multipart/form-data; boundary=---------------------------5618055171927212007156353948

await r2.text()
/*
"-----------------------------14683037551046622608547620079
Content-Disposition: form-data; name=\"test\"; filename=\"blob\"
Content-Type: application/octet-stream

data
-----------------------------14683037551046622608547620079--
"
*/

[sholladay]

Seems like Request really needs a setter for the URL or some way to modify the URL when cloning a Request. Doing so is far too difficult to do correctly at the moment. If we had that, we wouldn't need to compose requests to support searchParams and this bug could be completely avoided.

We should be able to workaround the bug by deleting the content type header first, as proposed in one of the open PRs, but that isn't a great solution. I wonder if we can reconfigure the request.url property to be writable... Still hacky, but better, IMO.

[gydroperit]

Current workaround - just delete header in beforeRequest hooks( should add at the end)

  beforeRequest: [
      ...,
      (request,_options) => {
        if(_options.body instanceof FormData){
          request.headers.delete('content-type');
          return new Request(request, _options)
        }
        return request;
      }
    ]