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!

1 Like

Hello!

Does it handle custom MIME with versioning?
For example, the both example below are valid values:

Accept: application/vnd.example.v1+json
Accept: application/vnd.example+json;version=1.0

However, it seems the second one is not working with MIME… Or maybe I’m doing something wrong?

There is a mechanism for you to define additional types. I think you will need to define each version as its own mime type.

3 Likes

Hello José, did you mean setting the types in the config :mime, :types (as it’s suppose to be done)?

Maybe, I was a bit confusing, sorry for that. I meant that I was able to define my own type using the following:

config :mime, :types,
  "application/vnd.example.v1+json" => ["v1"],
  "application/vnd.example.v2+json" => ["v2"]
}

However, It seems that the below version does not work, and it was basically my question (just wanted to be sure it doesn’t work as a MIME type):

config :mime, :types,
  "application/vnd.example+json;version=1" => ["v1"],
  "application/vnd.example+json;version=2" => ["v2"]
}

The way I tested it was to using a plug :accepts and it’s only working without the ;version=1.

Anyway, thank you for your time.

Just to be sure: did you force MIME to be recompiled so it picks your changes?

1 Like

Yes, I did. Double checked ervery time. Running after each change: mix deps.clean mime --build

The MIME that is using the semicolon separated version does not work (I mean the plug :accepts, ["v1"] errors kicks in with a 406 response (which is the expected behavior for a not compatible type, right?)

The one without the semicolon works as expected.

Hrm, so we need to see how the mime types are being parsed by Plug. Perhaps it rejects or discards what is after the question mark.