Add API entry points for custom and async mime lookup

[mk-pmb]

Hi, I'm trying to serve text files with unusual filename extensions, which wind up as octet-stream due to ecstatic's reliance on the "mime" module:

sven:/gr2$ nodejs -e 'console.log(require("mime").lookup("common.flp"));'
application/octet-stream

I'd prefer them to be resolved according to my local mime types DB:

sven:/gr2$ file --mime common.flp
common.flp: text/plain; charset=us-ascii

This could be achieved by using the "mime-magic" module:

sven:/gr2$ nodejs -e 'var mime = require("mime-magic"); mime("common.flp", console.log);'
null 'text/plain'

It seems that in the "mime" module, there's currently no way to distinguish known octet-streams from fallback octet-streams (mime bug #55).

I'd be glad if you could implement the mime-magic lookup into mainstream ecstatic.

(Edit 2015-12-08: The filename-based lookup is fine for default. If mime-magic lookup ever gets into mainstream ecstatic, only use it as a fallback for when filename-based mime has no idea.)

[jfhbrook]

Oh wow, mime-magic looks sick! I see two issues:

1. mime has a sync interface whereas mime-magic has an async interface
2. mime is pure javascript whereas mime-magic is a compiled extension

As far as sync/async: I don't really care, I'm just lazy. I'm not so sure about bringing in a compiled dependency if there's a good way to avoid it though; it's something I would need to ponder.

One suggestion: Did you know that you can customize mime's internal database with mime.define()? If that's good enough for what you're doing, then I guess the next question is, how do you combine that with ecstatic?

Keep in touch!

[jfhbrook]

If you do irc, hit me up in #stackvm on freenode.

[mk-pmb]

met him on IRC. decided to add two hooks for mime types:

1. export a reference to ecstatic's instance of the (mundane) mime module, to allow using .define({ ctype: fexts });on it. Update: Each instance of ecstatic should use its own instance of the mime module, to avoid conflicting overrides when a node app serves multiple sites on different ports.
2. convert mime lookup to continuation passing style and allow replacing the lookup function:

ecstatic.mimeLookup = function (fname, cb) { ... };
ecstatic.mimeLookup = require('mime-magic');

fix + pull request added to my todo.

[jfhbrook]

Sounds good!

[bnjmnt4n]

Has there been any progress for this issue? If you need a PR, I can do one sometime soon.

[mk-pmb]

Nope, didn't have time for it yet, or wasn't impacted bad enough by the problem, however you prefer to look at it. ;-) Would be nice if you solve it.

[jfhbrook]

Yeah, afaik nothing happened to fix this issue.

[mk-pmb]

Looking at this again, the initial approach seems like it might cause conflicts between multiple modules using ecstatic, so it'd probably be better to make the MIME lookup handler a per-instance option.

[dotnetCarpenter]

I would really like this in http-server, so guess this is the upstream repo to follow. It's a (REALLY) nice-to-have not a need-to-have, yet.

[mk-pmb]

Good news: I got the tests to work, all pass except some minor MIME variations.

I'd like to change our dependency on the old mime@^1 to the mundane-mime-v1 proxy package I just published. This way we can still use v1 for people who like to .load() Apache style MIME type lists, while at the same time allowing partial migration to the latest mime. Yes/no?

[jfhbrook]

Oh, to better enable replacing the dependency in a scenario where npm dedupes?

[mk-pmb]

Actually it was just the easiest way to make both versions live side by side on my machine without npm going on a rampage, enforcing default whitespace style in hundreds of package.jsons even when no values were changed. However, now considering your question, it might indeed have been a side effect of a dedupe attempt.

[mk-pmb]

I'll just go through with that change because my dev server just failed due to the limbo.

[jfhbrook]

Looks like this shoulda been closed with https://github.com/jfhbrook/node-ecstatic/pull/143/files