-
Notifications
You must be signed in to change notification settings - Fork 3k
Closed
Description
One thing that have bother me before is that the boundary header and the Blob's type can't work in sync.
what do i mean by that?
The boundary that gets generated in webkit (blink & safari) contains uppercase letters. Firefox seems to use only numbers and that is fine. But if you want to generate a blob out of a FormData for later use (for postMessaging, caching / reuse or what not) that's when you get into some issues.
When you construct a blob (or file) then the type is spec'ed to be transformed to all lowercased letters.
fd = new FormData()
res = new Response(fd)
res.headers.get('content-type') // "multipart/form-data; boundary=----WebKitFormBoundary4Abu3QeNVjbdNztI"
blob = await res.blob() // Blob { type: "multipart/form-data; boundary=----webkitformboundary4abu3qenvjbdnzti"}
res.headers.get('content-type') === blob.type // false
new Request(url, { method: 'POST', body: blob }) // use wrong content-type boundary (uses blob's type instead)- I had this issue a while back when i built my formdata polyfill that sends a generated blob out of formdata entries.
(I did have mixed upper/lower case letter but was resolved by removing the uppercase letters when generating a boundary) - I also had to explain it in a stackoverflow answer when i had to reuse the content more then once and explain that you can't rely on the blob type that is generated from
new Response(formData).blob()
This can be resolved if just all browser just didn't use any uppercase letters in the boundary. (or if the blob type wasn't casted to all lowercase letters)
Metadata
Metadata
Assignees
Labels
No labels