-
Notifications
You must be signed in to change notification settings - Fork 541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not getting the full type when parsing multipart/form-data #2283
Comments
would you like to send in a PR? |
Not this time... this time i think i will pass. |
Hi @jimmywarting and @KhafraDev. Can I work on this issue? |
fine by me |
The fix seems to require a change to |
@barronw Indeed, it comes from |
@fastify/busboy is a fork of busboy, the options are probably the same |
@KhafraDev @barronw I think that we can emit charset also |
@IlyasShabi if i would like then i could just send this var type = 'multipart/form-data; boundary=----WebKitFormBoundaryv9GiqHf1i48Tx1aI'
var otherFormData = new Blob(['123'], { type })
console.assert(otherFormData.type === type)
var fd = new FormData()
fd.set('embeded-formdata', otherFormData)
// later
fd = await request.formData()
console.assert(fd.get('embeded-formdata').type === type) i should be able to put in a file that have completely nonsense type new Blob(data, { type: 'x/y; foo=bar; fuz=123' }) and get back exactly the same thing. |
Bug Description
Not getting the full type when parsing multipart/form-data
Reproducible By
Expected Behavior
To get the full type,
text/plain;charset=utf-8
Logs & Screenshots
Screenshot of chrome:
Screenshot of NodeJS
Environment
Not using undici directly - using Node.js v20.6.1 built in fetch
Additional context
presumable this revolves around the usage around Busboy...
Maybe the type should be extracted from the headers instead...? to get the raw content-type.
The text was updated successfully, but these errors were encountered: