-
Notifications
You must be signed in to change notification settings - Fork 251
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
application/mp4 incorrectly maps to file extension mp4s. #207
Comments
Thank you for the report. It looks like the current mapping is coming from Apache. Can you clarify what the outcome you are looking for is? (a) add those two extensions to the list (b) remove the apache one from the list or (c) both? |
Ah, that's a bit odd, I would have expected the source to say "apache" as some other mime types in that list do. I've never heard of https://www.fileinfo.com As far as outcome, I would expect (c) to see both of those added to the list and |
Thanks! So the source is defined in the README as "where the mime type is defined.", and in this case, indeed the MIME type is defined in IANA. We do not include where the extensions are sourced from in the database. So there is good news and bad news on that: Good news -- I will look into what is keeping the extensions that are in IANA from showing up in our database |
Ref: Apache MIME types Snippet of that page:
Interesting text comment in the spec snippet. No reference to
Ref: https://tools.ietf.org/html/rfc4337
|
That's correct on Apache; of course registered types are in IANA. If we only cared about those we would never need to consume Apache :) We consume the Apache file in order to get the "unregistered" ones they provide, which is a lot of very useful ones not in the IANA database. |
Here we go for Ref: https://tools.ietf.org/html/rfc6381
Still no
|
So taking a look at our database, we do actually have a MIME type with So you want both |
P.S. if it helps at all, I just noticed the IANA registry points to an RFC that was obsoleted by other RFC. And that RFC notes that all these MPEG-related types and registered in their own alliance registry: http://mp4ra.org/ |
Depends on the hierarchy for this projects precedence or if it's peer leveled. MPEG anything catches my eye since I've worked on it in the past. Apple hasn't always registered their MIME types but it is in the Library of Congress link... so it's "kind of" there, in history. Because of rfc4337 conditionals it makes it a little more difficult. |
Well, as far as this project is concerned, we are not in the business to dig through documents and try and figure out what is "right" and what is not -- that is an entire project in of itself. The goal of this project is to simply aggregate the three sources listed at the top of the README into a nice little JSON file format in order for folks to consume.... So whatever those sources say is associated to what is what this module is going to say. The reason I'm asking those questions is in order to identify which of those three upstreams to correct if it's wrong or needs changing. |
Well it's the chicken in the egg syndrome in my book. One needs to get at the MIME type to determine if its a binary audio (conditional a in rfc4337) but this can be a "list" of MIME types usually included to determine the MIME type of a binary file in server side projects and flip it for client side. Personally I'd probably leave it as is. This is probably one of those "(common) unregistered types" in Apache... as long as
Yes but who has higher priority if any? IANA over Apache, etc. or do you just peer merge it discarding duplicates? |
It is just all merged together. For example, the MIME types is an object, so it's not possible to have duplicates. The extensions are just all joined together in the extensions array, for example. The goal is that if it exists in at least one of the sources, it exists in this database. |
Is it too big of a leap to show multiple sources on merge to help alleviate confusion? CSV separated (or pipes) or even a new field to show the precedence or would that be too breaking? |
We cannot make that type of change without a major version change and even changing the name of the db file, as this project really took off more than we ever expected, and there are so many folks just pulling the file direct from master all over the Internet... That field is in use by various folks as well. |
Okay... well I guess this is one of those paradoxes where one has to check existing issues to see if it's been explained from what source. Apache has one of the |
So this module does provide them split out in the |
Re: @Bdthomson
...
Just providing a possible explanation for the author of this issue. I'm sure you've said the same thing over and over through the years with this project but my focus is not always on GH searching. ;) Sometimes it helps to have another voice asking the questions to get it in different wording. :) Plus I get a little better understanding of this project and its use cases.
Good to know. Although programmatically may not be useful since it's usually accessed from all the merged... which is great but that's why I asked in priority in the final list. |
The |
Source IANA - https://www.iana.org/assignments/media-types/application/mp4 - "mp4 and mpg4"
https://github.com/jshttp/mime-db/blob/master/db.json#L908 - "mp4s"
The text was updated successfully, but these errors were encountered: