mime-types
mime-types copied to clipboard
jshttp
Add in new public function - lookupAll().
This is to address https://github.com/jshttp/mime-types/issues/23. The goal of this PR is add a function for looking up all MIME types associated to a file extension.
This would be useful for me to be able to create sets of acceptable MIME types for file validations without having to manually look up each potential MIME type with it. This happens to come up in a few examples (including bmp, rtf, and mp3 to name a few).
Hoping to have a conversation about what's good or not. I thought an initial implementation would be a good starting point.
Thanks for your work on this module!
Any questions about the PR? Or are there any changes I should make for this PR?
Any chance somebody can take a look at this? It still would be valuable to us if we can merge it in.
Conflicts over an extension are rarely the result of an actual difference in media types. Rather, they stem from uncertainty over what the mime type string should be. E.g. audio/wav vs audio/wave for the WAV file type. Same file type, same extension, just some confusion around the type string.
For v2 of the 'mime' module, I'm taking the stance that extension<->type string mappings should be deterministic and, thus, will be proactively (and arguably arbitrarily) resolving any conflicts as part of the build step in that module. This would make a lookupAll() method unnecessary in that module, as there will never be more than one type for a given extension. See https://github.com/broofa/node-mime/issues/162 for details.
Any news on that? For example .csv can be text/csv or application/vnd.ms-excel depending on OS. This improvement would be very useful.
FWIW, my arguments for why I'm reluctant to support this feature in mime: https://github.com/broofa/mime/issues/254#issuecomment-861525817
I'm not 100% against it, but I do question whether there's really enough value here to make it worth the trouble. I'm curious what your take is @dougwilson.
[Also, random aside: I notice you've created a "3.0" milestone for this. If you're planning a major release, I'd like to hear what you're planning, and if it might make sense to try to combine the mime and mime-types projects as part of that. I can create a new issue for that if it's something you're interested in exploring...?]
It's been so long I barely even remember the context of why I wanted this in the first place. That being said, I wanted to share what I can remember to at least express the motivation better. There may be a better answer than lookupAll.
If I remember right, it was something along the lines of attempting to provide validation on the type of file being received. Not so much from a security perspective, but more a usability perspective. An example: if a user is required to upload a CSV file to a site but it's MIME type is application/vnd.ms-excel, using lookup would say since extension is .csv then it must have a MIME type of text/csv. But the user has properly uploaded a file .csv with a MIME type of application/vnd.ms-excel which is good and we would accept. Of course an easy way to fix this app-side is to say that either MIME type works. It gets cumbersome when you accept a fairly wide array of types, especially when this library can give you a reasonably complete set of options.
It may not be worth the maintenance cost to add this into the API, it's true. So I genuinely don't know the right answer. It seemed like the right move for us at the time though.
Hopefully that helps!
It is more then two years after the last conversation and 6 years after this PR started. I use the lookup to map fileextensions to a mimetype. However, this will fail (sometimes) because I only get the first mimetype and not all mimetypes that are related. Long story short: Is this PR still making any change to bo merged or should I search for an alternative way?
If anyone still wants a simple reason to support this: file upload filter functionality requires passing in a full set of accepted extensions in most APIs.
So, for instance, .yml and .yaml are common extensions but you've got no built in way to get that full valid set from the public interface here.
FWIW, I just published the first beta release of mime@4. It adds support for a getAllExtensions() method.
https://github.com/broofa/mime/pull/287