I am using FormData and multipart/form-data to upload media files (i.e. video/mp4 and text/vtt).
I've tried numerous times to use base64 as my transfer encoding and apply Content Type (i.e. mimetype) of text/vtt for my sample.vtt file; however, multer continues to give me application/octet-stream.
Where are my headers ever applied?
I've looked through Busboy, Dicer, and Multer. I can't seem to find the use-case of the headers I've been sending.
Multer make-middleware line 33
busboy = new Busboy({ headers: req.headers, limits: limits, preservePath: preservePath })
Busboy main.js line 71
this._parser = type(this, cfg); where cfg contains our headers from multer
Busboy multipart.js line 24
function Multipart(boy, cfg) { follow cfg and you will never find headers used?
Busboy multipart.js line 124
part.on('header', function(header) { if headers are never passed to Dicer in line 98 (same file), then how will header ever have any of the values I've sent in my request?
Perhaps I'm having tunnel vision and can't see what's going on.
Can someone help?
@LinusU @ryhinchey @jonchurch @mscdex
Formidable writes their headers like so
Which version of Multer are you using?
Are you talking about headers for the different parts? or headers for the entire request?
What does your request look like on the wire?
Trying to upload a example.vtt file in multer 2.0
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Content-Length: 333
Content-Transfer-Encoding: base64
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary1ME0fBD7X0xjqj2q
```
**Response**
Notice the `detectedMimeType: null` and `detectedFileExtension: ''` are not found. The `clientReportedMimeType` is application/octet-stream.
Multer doesn't seem to like caption/subtitle media files.
{
fieldName: 'caption',
originalName: 'sample.vtt',
clientReportedMimeType: 'application/octet-stream',
clientReportedFileExtension: '.vtt',
path: 'C:\Users\User\AppData\Local\Temp\W2CC1VG',
size: 132,
detectedMimeType: null,
detectedFileExtension: '',
stream: ReadStream {
_readableState: [ReadableState],
readable: true,
_events: [Object: null prototype],
_eventsCount: 2,
_maxListeners: undefined,
path: 'C:\Users\User\AppData\Local\Temp\W2CC1VG',
fd: null,
flags: 'r',
mode: 438,
start: undefined,
end: Infinity,
autoClose: true,
pos: undefined,
bytesRead: 0,
closed: false,
[Symbol(kCapture)]: false,
[Symbol(kIsPerformingIO)]: false
}
}
```
Note: temp files hangs in my temp folder after successful or failed response until I restart app.
I'm not able to reproduce this behavior with code I've written myself. Can you provide a minimal reproducible example that shows the behavior?
In the simple upload test app I use to reproduce issues where I make a multipart upload from an html form, I'm sending a .vtt file as a single upload and multer is properly detecting the clientReportedMimeType as text/vtt.
I put my repro attempt into this codesandbox which points to this branch of my repo with the code.
I'm hoping to nail down if it's an issue with how you're making your request, or with Multer itself. Often there's an issue with how someone is making their request, but since we're working with the new version of Multer here, your feedback is highly valuable in making sure we aren't dealing with a bug here. Thanks!
Most helpful comment
I'm not able to reproduce this behavior with code I've written myself. Can you provide a minimal reproducible example that shows the behavior?
In the simple upload test app I use to reproduce issues where I make a multipart upload from an html form, I'm sending a
.vttfile as a single upload and multer is properly detecting theclientReportedMimeTypeastext/vtt.I put my repro attempt into this codesandbox which points to this branch of my repo with the code.
I'm hoping to nail down if it's an issue with how you're making your request, or with Multer itself. Often there's an issue with how someone is making their request, but since we're working with the new version of Multer here, your feedback is highly valuable in making sure we aren't dealing with a bug here. Thanks!