Fix multipart boundary mismatch #540
Conversation
kdelmonte
force-pushed
the
multipart-boundary-mismatch
branch
2 times, most recently
from
ead7dc5 to
8306b27
Compare
kdelmonte
force-pushed
the
multipart-boundary-mismatch
branch
from
8306b27 to
1a20029
Compare
kdelmonte
changed the title
|
@sholladay you were correct in your comment when you questioned if all options were being exposed as instance properties. Please let me know what you think about this change. |
source/core/constants.ts
Outdated
| @@ -58,3 +58,20 @@ export const kyOptionKeys: KyOptionsRegistry = { | |||
| onDownloadProgress: true, | |||
| fetch: true, | |||
| }; | |||
|
|
|||
| export const requestOptions = new Set([ | |||
There was a problem hiding this comment.
Is there any other way than having a hard-coded list here? We'll have to keep this up to date and if we miss something, it could cause problems.
There was a problem hiding this comment.
I really want to avoid this too. Let me give it some thought.
There was a problem hiding this comment.
Maybe a similar solution to the KyOptionsRegistry can be employed here to defer the list keeping to Typescript and undici. I will try this.
There was a problem hiding this comment.
So there are two RequestInit interfaces that are relevant here: the one exported from node's undici-types and the one exported from Typescript's lib.dom.d.ts.
Common fields present in both interfaces:
methodkeepaliveheadersbodyredirectintegritysignalcredentialsmodereferrerreferrerPolicywindow
Unique to undici-types:
dispatcherduplex
Unique to Typescript's lib.dom.d.ts:
cache
Standard Request Options as specified in MDN
Present in both undici-types and lib.dom.d.ts:
methodheadersbodymodecredentialsredirectreferrerreferrerPolicyintegritykeepalivesignal
Present only in lib.dom.d.ts:
cache
Missing in both undici-types and lib.dom.d.ts:
priority(⚠️ this field is still considered experimental but it is already supported in Chromium based browsers)
With all of this being said, I think we can leave priority out and let it be detected as an unknown property since it will still be passed down to fetch.
Please let me know what you think of this approach @sindresorhus and @sholladay.
There was a problem hiding this comment.
Yeah, that sounds like a good approach.
…ons based on Typescript interfaces
kdelmonte
force-pushed
the
multipart-boundary-mismatch
branch
from
a34f99b to
9560921
Compare
kdelmonte
changed the title
|
Thanks for the quick fix 👍 |
Turns out that the read-only
bodyproperty of the Request interface is not [yet] supported by Firefox which causes #539.Changes:
Fixes: #539 (introduced in #536)