Help testing Mime latest (upcoming v2)

Hi everyone,

I have started working on the v2 version of the Mime library, used by Plug and Phoenix. The previous version depended on an external Mime database, which made it complicated for us to handle corner cases and, often times, it was too large.

The new version starts a new database from scratch, which should be faster to compile, faster to run, and use less memory. However, it may be missing important mime types. Therefore, I would like to request the community help in two possible ways:

  1. Compare the list of supported extensions with the files you have in priv/static (or assets/static). Are all extensions listed? If not, please send a PR to add unsupported extensions.

  2. Use mime master as a dependency in your project and see if anything fails:

     {:mime, "~> 2.0", github: "elixir-plug/mime", override: true}
    

Your feedback is deeply appreciated!

27 Likes

On running mix deps.compile I get a warning

==> plug
Compiling 1 file (.erl)
Compiling 41 files (.ex)
warning: MIME.valid?/1 is undefined or private
  lib/plug/mime.ex:32: Plug.MIME.valid?/1

but otherwise no problems so far

Thank you! Note the warning is fixed on more recent plug versions.

1 Like

Willing to try, but I am not at my office at home. If I forget to report, please remind me :slight_smile:

Hey, José

I still think that using an external database is generally a good choice, even if it is something that is only manually updated and may generate a file that can be parsed during compile.

I maintain mime-types-data, and I’m happy to update the code there to generate something that is both smaller and easier to work with but more comprehensive than the ~76 types that I see now. (It’s pretty easy to filter the data so that only items with extensions are included (still probably larger than expected as there are 1,198 extensions known to the complete database and 824 extensions attached to 864 IANA registered types).

5 Likes

How will MIME v2 deal with Javascript files? The current MIME type list includes both application/javascript and text/javascript. It appears that the former was once meant to supercede the latter (a bit like XHTML and HTML), but according to MDN JavaScript files should always be served using the MIME type text/javascript.

Currently, application/javascript prevails between the two, but can be overriden by including text/javascript in the config :mime, :types map. This is obviously not ideal. If text/javascript is indeed the way to go, application/javascript should perhaps be removed, or at least text/javascript should be the default MIME type used in response headers.

Please send a PR so text/javascript prevails but we should still recognize other formats.

On my phone so apologies if I’m missing it, but is the InDesign file extension .ind included?

I see the .ps, .eps, .ai but I haven’t noticed the .ind yet.

Again, I’m on my phone so I might just be missing it when I look.

Update: maybe .ind was never supported and the preference is just to use .ai?

Got RSI, so spend so time off keyboard, hence the late reply.

Did not encounter any issues with importing it as a dep; didn’t find any files in priv/static not listed.

Found a small list in my code (which only checks for ‘zip’, image’ and ‘xml’) with a few Mime-types returned in content-type header. Those may not be ‘standard’ (hence my custom list) but maybe they are used more often. The mentioned RSI prevents me from investigating.

application.zip
application/x-zip-compressed

Thanks for the follow up and don’t worry about this. :slight_smile: Get better!