Skip to content
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

Add API entry points for custom and async mime lookup #66

Closed
mk-pmb opened this issue Apr 14, 2013 · 14 comments

Comments

Projects
None yet
4 participants
@mk-pmb
Copy link

commented Apr 14, 2013

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

This comment has been minimized.

Copy link
Owner

commented Apr 14, 2013

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

This comment has been minimized.

Copy link
Owner

commented Apr 14, 2013

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

@mk-pmb

This comment has been minimized.

Copy link
Author

commented Apr 15, 2013

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

This comment has been minimized.

Copy link
Owner

commented Apr 15, 2013

Sounds good!

@bnjmnt4n

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2014

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

@mk-pmb

This comment has been minimized.

Copy link
Author

commented Apr 2, 2014

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

This comment has been minimized.

Copy link
Owner

commented Apr 2, 2014

Yeah, afaik nothing happened to fix this issue.

@mk-pmb

This comment has been minimized.

Copy link
Author

commented Sep 22, 2014

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

This comment has been minimized.

Copy link
Collaborator

commented May 11, 2015

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 mk-pmb changed the title Add API entry points for modifying or replacing mime lookup Add API entry points for custom and async mime lookup Jun 9, 2017

@mk-pmb

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

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

This comment has been minimized.

Copy link
Owner

commented Oct 22, 2017

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

@mk-pmb

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

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

This comment has been minimized.

Copy link
Author

commented Oct 24, 2017

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

@jfhbrook

This comment has been minimized.

Copy link
Owner

commented Dec 16, 2017

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

@jfhbrook jfhbrook closed this Dec 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.