broofa / mime Goto Github PK
View Code? Open in Web Editor NEWMime types for JavaScript
License: MIT License
Mime types for JavaScript
License: MIT License
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!
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.
Which license are you going with?
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.
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
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
'font/woff': ['woff'],
'image/webp': ['webp'],
'text/cache-manifest': ['manifest'],
'text/x-component': ['htc'],
'application/x-chrome-extension': ['crx']
Hope this helps :-)
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.
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.
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.
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?
$ 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
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.
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
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"
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")
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.
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.
After researching for a while, these are the best definitions I could find:
text/x-lua
application/x-lua-bytecode
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 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.
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
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!
Currently there's no content-type in the list for gettext translation files (.po
).
gzip is doubled
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:
/.*[\.\/\\]/g
path
: path.extname(file) || path.basename(file)
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:
types.json
at all, use mime.define
in my app.types.json
file.types.json
only when needed.Thoughts?
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!
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
.
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.
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).
how to support plist?
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.
$ 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:
mime.lookup(_extension_)
will return the type defined by mime.types
rather than node.types
. E.g. mime.lookup('rtf') would be
application/rtf`mime.extension(_node_type_)
will return undefined
. E.g. mime.extension('text/rtf')
would be undefined
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
I would suggest adding two image mime-types:
image/pjpeg + image/x-png
progressive jpegs and some png format
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 .
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.
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.
The correct internet media type is text/x-handlebars-template
according to http://handlebarsjs.com/.
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 ]
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?
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
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.
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
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 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
Some of the mime types has changed. One of them is woff
which is now application/font-woff
.
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.
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...
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?
The recent font changes are pretty useful and would help clean up my Chrome console.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.