You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I also have a custom ky instance, named in my example "api". This instance is based on the afterResponseHook example, to manage API authentication.
afterResponse: [async(request,options,response)=>{if(response.status===401){// Get a fresh tokenconsttoken=awaitky('https://example.com/token').text();// Retry with the tokenrequest.headers.set('Authorization',`token ${token}`);returnky(request,options);}}]
I discovered that the call to ky(request, options) doesn't regenerate the "content-type" header, which creates a boundary mismatch between the header and the request content.
I looked in the ky source code, and it seems that a patch already exists, but only for requests with searchParams, which is not my case:
// To provide correct form boundary, Content-Type header should be deleted each time when new Request instantiated from another oneif(((supportsFormData&&this._options.bodyinstanceofglobalThis.FormData)||this._options.bodyinstanceofURLSearchParams)&&!(this._options.headers&&(this._options.headersasRecord<string,string>)['content-type'])){this.request.headers.delete('content-type');}
A quick, non-ideal workaround on your end might be to change ky(request, options) to just ky(request). Does that solve it?
As for a more permanent fix, perhaps we should move the code for deleting content-type out of the searchParams condition. Hopefully that doesn't break anything...
Hi,
I tried to upload some content with the FormData Web API and Ky (latest release).
Something like this:
I also have a custom ky instance, named in my example "api". This instance is based on the afterResponseHook example, to manage API authentication.
I discovered that the call to
ky(request, options)
doesn't regenerate the "content-type" header, which creates a boundary mismatch between the header and the request content.I looked in the ky source code, and it seems that a patch already exists, but only for requests with searchParams, which is not my case:
ky/source/core/Ky.ts
Line 194 in 585ebcb
ky/source/core/Ky.ts
Line 184 in 585ebcb
The text was updated successfully, but these errors were encountered: