broofa / mime Goto Github PK

The README.md says:

The .types file format is simple - See the types dir for examples.

But there is no types directory.
To my surprise, I couldn't find an example via google...

Could we add text/yaml? (As in e.g. Rails: https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/http/mime_types.rb).

Would the better mime type for MSI files be application/x-msi or application/x-ms-installer? I've seen the latter used on the web.

mime module on NPM hasn't been updated for last six months. I see dozens of changes have been committed since then. Do you have any plan to update it?

$ DEBUG=1 node -e "require('./mime')"

shows several extensions where node.types redefines a type defined in mime.types. Specifically:

node.types changes "rtf" extension type from application/rtf to text/rtf
node.types changes "bmp" extension type from image/bmp to image/x-ms-bmp
node.types changes "otf" extension type from application/x-font-otf to font/opentype
node.types changes "m3u8" extension type from application/vnd.apple.mpegurl to application/x-mpegURL
node.types changes "flac" extension type from audio/x-flac to audio/flac

Are there any objections to removing the definitions above from node.types? (Speak now or hold your peace!) Removing the node type has two impacts:

1. mime.lookup(_extension_) will return the type defined by mime.types rather than node.types. E.g. mime.lookup('rtf') would beapplication/rtf`
2. mime.extension(_node_type_) will return undefined. E.g. mime.extension('text/rtf') would be undefined

Currently there is no mime-type available for Opus audio. Would it be possible to add the audio/ogg; codecs=opus mime-type for files using a .opus extension?

For more info see the Opus documentation.

i'd prefer when a lookup fails, it returns something falsey like false instead of application/octet-stream. i would love to set the default type to something, but since it's global, i'm afraid it'll ruin other modules since this repo is used a lot.

aside from doing a major version bump, how about adding a second "default" option to the methods?

mime.lookup(file, false)

would return a valid mime type or false

Trying to get a mime type of a directory in /js request.uri, the module returns application/javascript. Is this the expected behavior? If it is, please explain why.

In my application, when a request comes for a static file, I check whether user has access to this type of static resource. For this reason I need to determine the file mime. Sometime when users enter /js, /css, in which case mime module returns as if request comes for JS or CSS files, respectively. Obviously, this is a wrong behavior.

The expected behavior in such cases is to receive null or '' (an empty string) which would be easy to handle in the application.

All, I've been a bit of an absentee landlord as far as maintaining this library goes. My response time on issues has been horrid, and that https://github.com/jshttp/mime-types exists is testament to the poor job I've been doing. For this I humbly apologize.

Moving forward, I'd like to insure this isn't an issue. So... What's the right thing to do here? Are there parties interested in being added as maintainers? (If so, who?) Should this library be deprecated in favor of mime-types? Could mime-types be pulled in here?

Hopefully I haven't completely alienated everyone. I'm genuinely interested in hearing everyone's opinions, and willing to do whatever the community thinks is best.

cc: @dominictarr @Fishrock123 @substack @jonathanong

After researching for a while, these are the best definitions I could find:

• lua - text/x-lua
• luac - application/x-lua-bytecode

Currently there's no content-type in the list for gettext translation files (.po).

The recent font changes are pretty useful and would help clean up my Chrome console.

I installed the module (fs, util, mime) in shared folder
written the below script

var fs = require("fs"),
    util = require("util");

var mime = require("mime");

var dataUri = base64Image("/home/arvindan/testing/abc.jpg");
console.log(dataUri);

function base64Image(src) {
    var data = fs.readFileSync(src).toString("base64");
    return util.format("data:%s;base64,%s", mime.lookup(src), data);
}

on execution throwing below error
Error: Cannot find module './types.json'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/home/arvindan/node_modules/mime/mime.js:87:13)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)

please help me to resolve the issue

how to support plist？

Specifying your license in package.json makes it a lot easier for your users to find and comply with GNU Affero licenses.

Also giving licenses (an array of objects with type and url keys) helps users whose legal departments request both the license name and the text. See this example from async:

  "licenses": [{
    "type": "MIT",
    "url": "https://github.com/caolan/async/raw/master/LICENSE"
  }]

Though licenses isn't specified in the npm package.json spec, it is supported by the NPM site, as you'll see if you check async's NPM page.

Thanks!

here log info:
info it worked if it ends with ok
verbose cli [ 'node', '/usr/bin/npm', 'install', 'mime' ]
info using [email protected]
info using [email protected]
verbose config file /home/shailendra/.npmrc
verbose config file /usr/etc/npmrc
verbose config file /usr/share/npm/npmrc
verbose cache add [ 'mime', null ]
silly cache add: name, spec, args [ undefined, 'mime', [ 'mime', null ] ]
verbose parsed url { pathname: 'mime', path: 'mime', href: 'mime' }
verbose addNamed [ 'mime', '' ]
verbose addNamed [ null, '' ]
silly name, range, hasData [ 'mime', '', false ]
verbose raw, before any munging mime
verbose url resolving [ 'https://registry.npmjs.org/', './mime' ]
verbose url resolved https://registry.npmjs.org/mime
http GET https://registry.npmjs.org/mime
ERR! Error: failed to fetch from registry: mime
ERR! at /usr/share/npm/lib/utils/npm-registry-client/get.js:139:12
ERR! at cb (/usr/share/npm/lib/utils/npm-registry-client/request.js:31:9)
ERR! at Request._callback (/usr/share/npm/lib/utils/npm-registry-client/request.js:136:18)
ERR! at Request.callback (/usr/lib/nodejs/request/main.js:119:22)
ERR! at Request. (/usr/lib/nodejs/request/main.js:212:58)
ERR! at Request.emit (events.js:88:20)
ERR! at ClientRequest. (/usr/lib/nodejs/request/main.js:412:12)
ERR! at ClientRequest.emit (events.js:67:17)
ERR! at HTTPParser.onIncoming (http.js:1261:11)
ERR! at HTTPParser.onHeadersComplete (http.js:102:31)
ERR! You may report this log at:
ERR! http://bugs.debian.org/npm
ERR! or use
ERR! reportbug --attach /home/shailendra/npm-debug.log npm
ERR!
ERR! System Linux 3.8.0-37-generic
ERR! command "node" "/usr/bin/npm" "install" "mime"
ERR! cwd /home/shailendra
ERR! node -v v0.6.12
ERR! npm -v 1.1.4
ERR! message failed to fetch from registry: mime
verbose exit [ 1, true ]

First off, thanks for the mime library. It's so simple and exactly what I need every time.

Recently, I've been working on a project that uses character sets base on custom mime types. This is similar to the API I have been using and I would like to suggest it as an addition to this library.

mime.charsets.lookup(mime, fallback)

Same as current implementation in terms of arguments and what it returns. Like Apache's AddDefaultCharset, this should return "UTF-8" if and only if mime is either text/plain or text/html. This, however, is only for the sake of convention.

mime.charsets.lookup("text/plain") -> "UTF-8"
mime.charsets.lookup("image/png") -> fallback or undefined

mime.charsets.define(obj)

The keys of obj are mime types and values of obj are charsets. Unlike mime.define(), values must be a String, not an Array. Previously declared mime types should be overridden.

mime.charsets.define({
    "application/x-my-type": "UTF-16"
})
mime.charsets.lookup("application/x-my-type") -> "UTF-16"

mime.charsets.add(mime, charset)

Sets a charset based on the mime. Not in the spirit node-mime however this is an attempt to (somewhat) follow Apache's addCharset. This is obviously optional as mime.charsets.define(obj) duplicates this functionality.

mime.charsets.add("application/x-my-type", "UTF-16")
mime.charsets.lookup("application/x-my-type") -> "UTF-16"

Additionally, one could easily replicate Apache's addCharset by running:

mime.charsets.add(mime.lookup("x-mt"), "UTF-16")

Notes

Internally, node-mime should hold an Object of mime types pointing to a specific charset. Node-mime should also set mime.default_charset to 'UTF-8'. Whether or not this is the default for all mimes starting in text/* or just text/plain and text/html is up to you.

If you have neither the time nor the will, I would be happy to whip up a simple implementation and submit a pull-request.

WOFF file format 2.0 (http://dev.w3.org/webfonts/WOFF2/spec/#IMT) is now used by Google Font.
It would be great to add "application/font-woff2" mime type for ".woff2" files.

See also this change in "mime-db" module : jshttp/mime-db@a7cb52f

Most of the recent pull requests contained commits that tried to change the mime.types file instead of node.types.

I suspect this is because the majority of people don't read wikis and few ever read the README.md carefully (thus not seeing / following the "requesting new types" link to the wiki).

So, I think it would be better to just move the information from the wiki somewhere where it can be immediately visible, like, for example, in the README.md or maybe into a CONTRIBUTING.md file.

Do you think it is within the scope of your project to include a mime type parser? Something that when presented with a string like 'text/plain; charset=utf8' would return an object like this:

{
    type: 'text',
    subtype: 'plain',
    parameters: {
       charset: 'utf8'
    }
}

I've already written code that pretty much does this (just needs some cleaning up) that I would be happy to contribute.

Hi

The last version of the npm module (1.2.1) is from January. WIll it be possible to bump the version to benefits of the apache list changed made during april ? Thanks.

Hi. Just a small bug. The filename 'image.jpg' will return a mime type of 'image/jpeg' while the filename 'IMAGE.JPG' will not. This can be fixed by adding a simple .toLowerCase() to the filename before sending it to path.extname(). I can submit a patch if you like.

I would suggest adding two image mime-types:
image/pjpeg + image/x-png
progressive jpegs and some png format

In some protocols(Google Discovery in my case) MIME globing patterns is used.
I implement function that do expansion of such patterns:

"/" => ["application/octet-stream"]
"video/*"=> [ "video/1d-interleaved-parityfec", "video/3gpp", ...]

I want create PR with these feature.
Do you interested in adding such feature?

mime.define({ 'browserid': 'application/json' });

mime.lookup('/www/.well-known/browserid'); // application/json
mime.lookup('\\www\\.well-known\\browserid'); // application/octet-stream

This is because the regex matches well-known\\browserid. I can think of 2 fixes here:

1. Add a backslash to the regex: /.*[\.\/\\]/g
2. Or removing regexes, and relying on path: path.extname(file) || path.basename(file)

When I looked at the doco, one of the first things I thought was what happened if you put in an unknown file extension.

In this case, I noticed it returns "application/octet-stream".

It'll be good to put that upfront in the README because I'm sure this is one of the first things people think about.

What do you think?

BTW, thanks for such a useful package!

Chris

'font/woff': ['woff'],
'image/webp': ['webp'],
'text/cache-manifest': ['manifest'],
'text/x-component': ['htc'],
'application/x-chrome-extension': ['crx']

Hope this helps :-)

It throws ;)

$ DEBUG_MIME=1 node -pe 'require("mime");0'

node_modules\mime\mime.js:26
        console.warn(this._loading.replace(/.*\//, ''), 'changes "' + exts[i]
                                   ^
TypeError: Cannot call method 'replace' of undefined
    at Mime.define (node_modules\mime\mime.js:26:36)
    at Object.<anonymous> (node_modules\mime\mime.js:87:6)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at [eval]:1:1
    at Object.<anonymous> ([eval]-wrapper:6:22)

In general,

mime.lookup('/path/to/file.css');  // ==>  text/css   the result is ok
mime.lookup('file.css'); // ==>  text/css   the result is ok
mime.lookup('.css'); // ==>  text/css   the result is ok
mime.lookup('css'); // ==>  text/css   the result is ok
//but
mime.lookup('path/to/css');  // ==>  text/css  . the result is　controversial

gzip is doubled

When looking up a types, check hasOwnProperty - we don't want to pretend that __defineGetter__ is a valid file extension whose MIME type is a function.

I'm going to delete the fork I have setup. That may close the pull request automatically. Let's consider this issue a place holder for the conversation.

Project link: http://laktak.github.io/hjson/
Mime type: text/hjson
File extension: hjson

Cross referencing some concerns:
hjson/hjson#12

Thanks!

Mime type for woff files should be application/font-woff and not application/x-font-woff, see http://www.w3.org/TR/WOFF/#appendix-b .

One lone missing semicolon:

Line 102

mime.charsets = {
  lookup: function(mimeType, fallback) {
    // Assume text types are utf8
    return (/^text\//).test(mimeType) ? 'UTF-8' : fallback;
  }
} ; // <-- this semicolon is missing

Thoughts about adding a property like commonName that provides a short, commonly used label for certain types?

e.g.
text/calendar is commonly known as iCalendar.

This is coming up for me because I am building an app that displays file types as a dropdown list for end users.

Some of the mime types has changed. One of them is woff which is now application/font-woff.

The correct internet media type is text/x-handlebars-template according to http://handlebarsjs.com/.

In mime.js

charsets: {
   lookup: function (mimeType, fallback) {
     // Assume text types are utf8.  Modify mime logic as needed.
     return (/^text\//).test(mimeType) ? 'UTF-8' : fallback;
   }
 }

I have many static file that's not utf-8 encoded, when access from web server like connect, the browser display mess.

If leave charset empty, the browser will itself detect charset of the content, and display correctly.

Hello,

This used to work in mime:

mime.define({
    'application/x-foo; type=bar': ['baz']
});

assert.equal('baz', mime.extension('application/x-foo; type=bar'));

It no longer does, given the extension logic currently splits off parameters after the ; (it looks like there was a previous bug fix for this given charsets, etc.).

I would have sent a PR, but given the history there I'm not sure what you want to do with it; it sort of feels like you need an API flag that indicates whether you want "exact match" (modulo whitespace) or "parameterized match" or something that does what it does now.

Which license are you going with?

i think it's assumed by default, but i'd rather be explicit when sending these type of headers otherwise IE might choke. i think we have a closed issue for that in Express.

when setting the mime type for .wav files internet explore is a bit picky...

valid options are: audio/wav, audio/wave, audio/x-wave, audio/vnd.wave

Chrome happily accepts the "audio/x-wav" but IE does not.

Hi,

Is it possible to add subj? If so I could prepare a pull request. The idea is to have default, filled in mime instance and provide a class that could be used to have absolutely own non-defaults mime types object something like this: https://github.com/nodeca/static-lulz/blob/master/lib/static_lulz/mime.js.

Man, @broofa! You're a hard person to find an email address for! I'm thinking at this point we should just transfer ownership of this project to you. I'm clearly not as invested in it as you are, and it makes sense to me to make the ownership reflect that. If you think that would be confusing or something, we can leave it here, but if it is something that you are interested in, just say the word and I'll make it happen.

Thanks again for working hard to respond to people's requests and questions, and just being insanely on top of things. Every time I say, all right I'll get around to those node-mime issues/pull-requests (usually a day or four later) you've already done it! You've really made this an reliable and useful tool to the node community. So good work!

And let me know!

running npm install mime currently fails (as does npm install [email protected]) with error:

npm ERR! Failed unpacking the tarball.
npm ERR! This is very rare. Perhaps the 'gzip' or 'tar' configs
npm ERR! are set improperly?
npm ERR!
npm ERR! couldn't unpack /tmp/npm-1296371367812/1296371367812-0.4462986506987363/tmp.tgz to /tmp/npm-1296371367812/1296371367812-0.4462986506987363/contents
npm ERR! Error installing [email protected]
npm ERR! Error: Failed /bin/gtar "-vxpf" "-" "-C" "/tmp/npm-1296371367812/1296371367812-0.4462986506987363/contents"
npm ERR! exited with 2
npm ERR!     at ChildProcess.<anonymous> (/home/xxxxxxxx/lib/node/.npm/npm/0.2.16/package/lib/utils/exec.js:48:8)
npm ERR!     at ChildProcess.emit (events.js:45:17)
npm ERR!     at ChildProcess.onexit (child_process.js:171:12)

npm install [email protected] works as expected.

I'm writing unit tests for ecstatic's new custom mime-type feature and can't do a proper teardown between tests due to a number of reasons. But the main one, that stops me right now, is that mime doesn't have a reset-mime-types function.

I can do mime = new mime.Mime(); but that doesn't load the default types.

// Define built-in types
mime.define(require('./types.json'));

// Default type
mime.default_type = mime.lookup('bin');

Could you add a reset-mime-types function, please?

there are a bunch of mime types i want to add as well as features. for now, i just created https://github.com/expressjs/mime-extended instead of bothering making PRs.

do you want to share maintenance? you could add me as a collaborator or i can add you to the expressjs org and you can move this repo to the organization. this library is pretty much used everywhere in node, so it would be nice if there were more collaborators.

this module would play very nicely with a lot of mime-related utilities in the organization like https://github.com/expressjs/compressible

I am using this module in a web application installed and bundled using JSPM. It works fine from what I can tell. However, I am actually only using a subset of the mime types. I can use mime.define but because mime.js requires types.json the entire file is bundled anyway when I build the application. This is probably not an issue since types.json is fairly small but for an optimal web app I see three options:

1. Fork this module to be API only, doesn't load types.json at all, use mime.define in my app.
2. Fork this module to create a smaller custom types.json file.
3. Somehow modify this module to load types.json only when needed.

Thoughts?

$ npm install mime

ERR! Error: shasum check failed for ...../tmp.tgz
ERR! Expected: c7a13f33a7073d9900f288436b06b3a16200865b
ERR! Actual: 3bb7b8a676e95a33a0f28f081cf860176b8f67c7

Hi!

Is index.js meant to be a symlink to mime.js? If so, please, make it real symlink

--Vladimir