mime-types / mime-types-data Goto Github PK

Hi

You appear to have no branches and from what I can tell from your recent commits this gem now requires ruby 2.

I use an old version of the fog gem via an elastic search chef cookbook which eventually depends on this gem but I am also running on an old version of chef which uses Ruby 1.9.

Now I cannot boot new elastic search servers because I do not have ruby 2. Any chance of a tag from before you required Ruby 2?

Hi!
Recently I wanted to use MIME::Types.type_for to detect a file content type, but I receive nothing when I try to detect the content type of a JFIF file.

MIME::Types.type_for("something.jpeg")
=> [#<MIME::Type: image/jpeg>]
MIME::Types.type_for("something.jfif")
=> []

Expected result:
This should return [#<MIME::Type: image/jpeg>]

Actual result:
it returns an empty array

The release process is relatively fast, but it should be automated as much as possible.

The release process looks like this:

1. Review any outstanding issues or pull requests to see if anything needs to be addressed. This is necessary because there is currently no automated source for extensions for the thousands of MIME entries. (Suggestions and/or pull requests for same would be deeply appreciated.)
2. bundle install
3. bundle exec rake mime:apache
4. bundle exec rake mime:iana
5. Review the changes to make sure that the changes are sane. The IANA data source changes from time to time, resulting in big changes or even a broken step 4. (The most recent change was the addition of the font/* top-level category.)
6. bundle exec rake convert
7. bundle exec rake update:version (This is new as of today.)
8. Write up the changes in History.md. If any PRs have been merged, these should be noted specifically.
9. Commit the changes and push to GitHub.
10. bundle exec rake release VERSION=newversion.

Some thoughts on this:

1. Any automation would have to go through a two stage process. The first stage would execute stages 3 and 4 because the JSON and column changes are noisier than the YAML changes. It would submit a pull request.
2. On approval/merge of an automation-generated pull request, the automation could execute steps 6–10, adding summary information to the History.md about the particular release.
3. A small change would have to be made suppressing Hoe.plugin :doofus for automation (but it should not be suppressed for human-based releases).

I think this needs to be done, but I have no time to implement such automation, nor am I running a server anywhere that could host it.

Your readme claims the following:

This registry contains the MIME media types in three formats:

A YAML format matching the Ruby mime-types library objects (MIME::Type). This is the primary user-editable format.

So I'd expect that the gem ships the YAML data as well, but that is not true. Could you please clarify the readme a bit? Or the gem of course ...

Thank you.

Some mime types come from IANA, right?

Is there some way to have separate data sources based on different orgs, e.g. IANA, Apache, Unofficial, etc.

Does that even make sense?

I'm looking at the text mime types.

I see text/plain includes markdown and md as extensions, but I also see text/markdown but without any extensions listed.

http://stackoverflow.com/questions/10701983/what-is-the-mime-type-for-markdown

Is this a bug?

This gem prefers image/x-bmp (reference) but image/bmp should be used instead.

image/bmp is documented here: https://www.iana.org/assignments/media-types/image/bmp

Please add application/x-rpm or application/x-redhat-package-manager for rpm files. RPM is a widely used format for software packages in Linux.

https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml

It's ok if files ending with .ai acquire a MIME type of application/pdf, although the preferred MIME type for .ai files should really be application/vnd.adobe.illustrator.

It is not fine that the preferred filename extension for application/pdf is suddenly and abruptly changed from .pdf to .ai.

Billions of PDF documents around the world have nothing to do with Illustrator.

Downloading a file of application/pdf should default to a filename with a suffix of .pdf. It must not default to .ai.

The only content type that should default to a suffix of .ai, should be application/vnd.adobe.illustrator.

The format of the Licence.md file, while purporting to be MIT, contains preamble copyright that makes the actual license distinct from MIT. Indeed, many automated license tools do not recognize this license as MIT due to the non-standard preamble.

Would you be amenable to using the standard MIT License text for this file?

As one example, licensee (and by extension, GitHub, which leverages licensee), does not consider this licensed under MIT.

https://api.github.com/repos/mime-types/mime-types-data/license

license: {
  key: "other",
  name: "Other",
  spdx_id: "NOASSERTION",
  url: null,
  node_id: "MDc6TGljZW5zZTA="
}

Corresponding license response for rails, which is recognized as MIT: https://api.github.com/repos/rails/rails/license

license: {
  key: "mit",
  name: "MIT License",
  spdx_id: "MIT",
  url: "https://api.github.com/licenses/mit",
  node_id: "MDc6TGljZW5zZTEz"
}

I would be willing to open the PR for this, if it would be considered. Thanks!

#53 reworks the handling of the provisional media type registry in order to avoid a duplicate error on application/netcdf (see #50).

However, since types/provisional-standard-types.yaml has been removed, there is no way to see if types were removed from the provisional registry because the standard or the provisional registration was withdrawn. (The current handling should properly handle upgrades from provisional to registration.)

In order to keep the data clean, we need to resolve this.

Hello! Firstly, thanks for this project. It makes my project much easier to maintain, and for that I'm always grateful!

I would like my plugin to support avif images, but mime-types doesn't know about it yet. Can y'all teach it? It's in the IANA list.

Is this dependency really required ? There is a lot of gems depending on mime-types that are impacted by this new constraint.

> MIME::Types.of("js").map(&:obsolete?)
=> [true, true, true]

Was this the case before? I don't think so?

It looks like something changed between 3.2018.0812 and 3.2016.0521 (perhaps the data and tooling update from 10 days ago) which changed the priority and contents of mime types for JavaScript files.

Previously in the 3.2016.0521 release, .js files were identified as application/javascript through mime-types:

>> MIME::Types.type_for('test.js')
=> [#<MIME::Type: application/javascript>, #<MIME::Type: text/javascript>, #<MIME::Type: application/x-javascript>]

In the subsequent 3.2018.0812 release, they're being identified as application/ecmascript:

>> MIME::Types.type_for('test.js')
=> [#<MIME::Type: application/ecmascript>, #<MIME::Type: application/javascript>, #<MIME::Type: text/ecmascript>, #<MIME::Type: text/javascript>, #<MIME::Type: application/x-javascript>]

Was this intentional? Or am I doing something wrong?

This gem lists .ai files as application/postscript, but Adobe Illustrator hasn't used EPS as its native format since 2000 or so. Version 9 and onwards save artwork as ordinary PDFs with editor-specific metadata included.

See github-linguist/linguist#4572 for a related discussion.

/cc @lildude

Hello @halostatue,

First of all, thanks for maintaining this project.

I was wondering if you already evaluated including mime types for RAW images. I cannot find any official documentation about this topic, but a Stack Overflow question seems to indicate that they do exist (there is a broken link in the chosen answer, it should have linked to this XML file).

Would you accept a PR which adds those mime types?

Thanks, Alessio

audio/x-wav exists, but audio/wav is missing. WAV has been standardized for a long time—can we add it?

See: https://tools.ietf.org/html/rfc7763

Is there a reason the application/csv MIME type is not included with extension csv?

file -b --mime some_file.csv returns this MIME type for some files on Ubuntu 20.04.

Assume it's happening because of the alphabetical order, but anyway I guess "video/mp4" should be preferred.
Also shouldn't file.m4v also return "video/x-m4v" instead of "video/vnd.objectvideo" (which according to IANA is for .mp4 also) as it's not being standardized?